ukoda wrote: » I thought it was for WHERE it's being used. Not a thread for rehashing old design arguments that have been closed off in many other threads.
Sam Russell wrote: » It is both HOW and WHERE Eircode has been implemented. Discussions here have been on the use by SUSI getting Eircodes to speed processing grant applications - that is a HOW it is used example. I am sure there are many other examples of innovative uses (quoted by yourself) that are better filed under HOW than WHERE. [The design arguments are for another thread unless they impact on implementation.]
ukoda wrote: » It's unfair for users to blame the design of eircode because one person/organisation decided to use the routing keys to display their results. As I've pointed out, it's not a limitation of the design, the design allows any form of presentation of data.
Sam Russell wrote: » Is the decision to use such large routing keys affecting the take up of Eircode for many or specific uses?
plodder wrote: » GJG wrote: » Plodder, you are stumbling towards the answer there. Sure, be they in the UK (up to 26 residences in each postcode) or in Germany (up to 100,000), people can use the arbitrary postcode areas for organising data or other items. Of course it is normally only a coincidence that the areas are suitable for the use, though as you say, in the UK areas can be combined if they are too small, though even that may not be perfect where a very specific boundary is needed (say, a watershed). But there are thousands of potential uses, and no 'size' is going to suit them all, unless it is done the way Eircode does it - have one residence per code. Then you can combine them any way you want, so the system suits any use. You're mixing up a few different things there. The fact that Eircodes are unique per household is not relevant to the question of whether routing keys are a useful index for aggregate statistics like house prices. We are looking at this from the point of view of the consumer of the statistics (eg estate agents) not from the generator of the statistics. The whole point of statistics is to give you an overview without having to look at individual data points. Let me elaborate the point. There are around 37 different routing keys in the Dublin area. So, if house prices go up in Swords, but down in Lucan, then you can see that because those areas have different routing keys. On the other hand, most of Galway is covered by one routing key (H91), covering a population of around 250,000 people. If house prices go up in Galway city but down in Gort, then you won't see that in the statistics because they are all lumped in together. The question is why did they create those massive routing key areas like H91? Why didn't they subdivide them into smaller areas? You seem to be saying, that's all very well for house price statistics, but how can you be sure that a subdivision that suits house prices, would be useful for other uses? I'm saying that's nonsense because any subdivision would be better than none at all. Here is a page showing the data indexed by routing key:http://www.cso.ie/px/pxeirestat/Statire/SelectVarVal/Define.asp?maintable=HPA04&PLanguage=0
GJG wrote: » Plodder, you are stumbling towards the answer there. Sure, be they in the UK (up to 26 residences in each postcode) or in Germany (up to 100,000), people can use the arbitrary postcode areas for organising data or other items. Of course it is normally only a coincidence that the areas are suitable for the use, though as you say, in the UK areas can be combined if they are too small, though even that may not be perfect where a very specific boundary is needed (say, a watershed). But there are thousands of potential uses, and no 'size' is going to suit them all, unless it is done the way Eircode does it - have one residence per code. Then you can combine them any way you want, so the system suits any use.
plodder wrote: » A poster came on here saying - Look, the CSO are using eircodes with their house price index. Are we not allowed to discuss the pros and cons of eircode's design in the context of that usage? If not, then this thread is purely a vehicle for people who are involved in the project to get free publicity for it. I don't see the point in that. It's supposed to be a discussion site.
GJG wrote: » Of course any subdivision for, say house price stats, is useful; but that doesn't meant that the system should be build around optimising it for that single use - there are thousands of others, many contradictory. Some levels of granularity would be unacceptable for some uses - say HIV infections in UK-sized postcodes. Other levels of granularity would be useless for other uses - say immunisation rates, where a large area doesn't show pockets deviating from the average.
It seems to me that Eircode went to lengths to emphasize that they weren't creating areas, although obviously people could map the routing keys, as in this case. However it's a bit rich to insist on doing this, and then complain that it doesn't work.
Every eircode has a lat/long attached to it, and a very simple procedure can assign it to any sized subdivision that you want. Sure, use the shorthand of the routing keys if you want and they suit you, but if they don't suit your use, map the eircodes to areas that work for you.
ukoda wrote: » I think there's been enough threads used as a vehicle to bash eircode, I'm not opposed to a thread that doesn't keep going over the same old arguments of the design. Otherwise is every thread to be a moaning ground for people who don't like the design of eircode?
plodder wrote: » Transparent attempt to shut discussion down that might be perceived as negative towards Eircode. I think I have been fair on the whole issue. I always acknowledge Eircode's good and bad points. So, when someone announces here that Eircode is now being used in some way, I will continue to comment on that, good and bad.
ukoda wrote: » And I'm sure you'll be able to distinguish design related items to the choices people and organisations make in displaying their data.
plodder wrote: » Public statistics have to be related to areas that people can identify with. Formerly, that had to be counties.
ukoda wrote: » plodder wrote: Public statistics have to be related to areas that people can identify with. Formerly, that had to be counties. The design of eircode does not preclude doing that.
plodder wrote: Public statistics have to be related to areas that people can identify with. Formerly, that had to be counties.
I'll repeat what I said earlier, the CSO does not have to use the routing keys. They can display data any way they want and relate it any way they want, by routing key, county, townland, north south east west, groups of small areas labelled any way they want, to make them relatable to any person, people or scenario. NOTHING in the design of eircode prohibits them doing that. The design benefit of eircode is that you can group them any way you want and in my opinion it's a good thing that the routing keys don't allow people take a lazy option and use a one size fits all approach. If the routing keys were more relatable then everything would be shoehorned into them weather they fit or not.
plodder wrote: » You keep on looking at it from the point of view of Eircode licensees or software developers who have access to Eircode lookups. You need to start looking at it from users' point of view, who aren't able to display anything. They just look at whatever the first category of people give to them.
ukoda wrote: » This example we are discussing is the CSO, tell me they dont have a licence to eircode? Of course they do. The "user" in this scenario is the public, and I'll say it again- the CSO can choose to display their statistics to the public any way they want - interactive maps, by routing key, by county, by townland, by small areas, by groups of small areas etc etc.
plodder wrote: » The dataset has to be indexed by something that :- a) covers the entire country b) is meaningful to the public, and c) is the right size for the job. Small areas are too small. Townlands are too small. An interactive map would work, except that you still need to be able to refer to areas by a name or a code, so you end up having to invent new codes, and expect people to remember them. Counties and routing keys are the only things that fit the bill. But, a hierarchical postcode would have been the best solution for this, because then you would have groups of small areas, with names that the public are already familiar with.
PDVerse wrote: » Small areas are aggregated into Electoral Divisions. There are approximately 3,400 of these, and they are named. They aggregate into Counties. CSO have zero requirement for another hierarchy in a postcode. The design provides everything they need which is why they've implemented Eircode fully. I've used CSO data in my work for the past 23 years, this isn't a debatable point. We train our new employees to present map and tabular CSO data at the appropriate hierarchical level given the use case.
plodder wrote: » My point stands that the huge and unjustifiable variation in routing key area size has diminished their usefulness for such purposes. Neither small area codes nor electoral divisions form part of the code itself. Therefore, they are of limited use as identifiers for statistics, because people won't be familiar with them.
plodder wrote: » I've put my reply to PDVerse on the "design" thread. Frankly, it's ridiculous that there are at least three different threads devoted to Eircode. Why can't we just have one? I'm sure it's boring the socks of people who aren't interested in the subject.
PDVerse wrote: » It isn't that implementations have required a workaround to deal with the variation in Routing Key size, it is simply a non-issue.
oscarBravo wrote: » This tallies with my experience. I simply don't care about routing keys; they're all but irrelevant to my use of Eircodes.
Bray Head wrote: » My substantive point was that the CSO used eircodes to generate the index by using it as a tool to match the Revenue data with the SEAI BER data.
The presentation of data by routing key is interesting if beside the point, something like this could exist with a UK- or German-style postcode of course. However the index could not have been generated at all had a unique identifier approach not been given the prevalence of non-unique addresses in Ireland.
