Eircode - its implemetation (merged)

Sam Russell · 25-09-2016 12:36PM

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.

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 · 25-09-2016 12:40PM

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.]

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 · 25-09-2016 12:53PM

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.

Is the decision to use such large routing keys affecting the take up of Eircode for many or specific uses?

ukoda · 25-09-2016 01:01PM

Sam Russell wrote: »

Is the decision to use such large routing keys affecting the take up of Eircode for many or specific uses?

What metrics would you use to measure that? Per Autoaddress Twitter approx. 27,000 couriers used their app to get directions in the last 30 days. Nightline have attributed eircode to being able to expand, as have Fastway couriers, but we were told by the FTAI that it's useless?!

It's being used more and more places and usage will continue to grow, are you asking me if growth would be faster if the routing areas were smalller? How could anyone possibly measure that? All I can could do is guess, and I'd guess that the size of the routing keys hadn't made any significant impact on the take up

GJG · 25-09-2016 03:25PM

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

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.

plodder · 25-09-2016 03:35PM

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.

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.

ukoda · 25-09-2016 03:44PM

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.

As I said, the design of eircode does not mean that you HAVE to display statistics by routing key, one organisation has chosen to do so. And people are back in with "ah sure that's cos the design is crap" which is totally wrong as they've taken one organisations CHOICE of data display and decided to trot out the old "bad design" argument yet again. The design allows you to aggregate data any way you want.

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 · 25-09-2016 03:57PM

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.

I disagree. Any subdivision would have been better than none at all. That's why small areas were created. They are about as small as you can get while preserving anonymity and were an ideal candidate to build the structure of the code on.

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.

Well, they could have created a completely random code, but they didn't. So, in effect they created areas around the routing keys. They might not want people to use them. So, someone better tell the CSO. Though the truth is that postcode areas are useful and you can't stop people using them.

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.

But there is an advantage to using public identifiers (eg counties, routing keys etc) because the areas are easily identifiable. I assume that is why the CSO did it.

plodder · 25-09-2016 04:05PM

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?

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 · 25-09-2016 04:07PM

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.

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 · 25-09-2016 04:26PM

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.

No, it isn't simply a case of organisations choosing to display data in a particular way. Public statistics have to be related to areas that people can identify with. Formerly, that had to be counties. Now, we have the additional possibility of Eircode routing keys. Believe it or not - doing this may increase usage of Eircode.

And being fair about it, for a lot of the country the routing keys are reasonably consistent and somewhat useful. It's only fair however, to question the outliers that are a lot less so.

ukoda · 25-09-2016 05:03PM

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. 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 · 25-09-2016 07:21PM

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.

It does really. It was Eircode's decision to make H91 cover most of Co. Galway and parts of Mayo and Clare. They could have designed it so that the public part of the code was down to a much finer granularity than that. But, they didn't. Other posters seem to be able to accept that much at least.

Let me put it another way. If the CSO don't index these stats by routing key or county name, then what would you suggest they use instead?

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.

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 · 25-09-2016 07:26PM

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.

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 · 25-09-2016 07:42PM

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.

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.

ukoda · 25-09-2016 08:06PM

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.

If I'm looking at a map that's point and click then I don't need to remember anything. The CSO in the background no doubt have a lot more granular detail they work from.

clewbays · 25-09-2016 08:48PM

Table 16 in the following link gives a rough indication of the number of dwellings in each routing key and it is very uneven: http://www.cso.ie/en/releasesandpublications/er/dber/domesticbuildingenergyratingsquarter22016/

Auctioneers and other users are generally not going to be able to take individual Eircodes and convert them into a different geography (would require GIS capability if the alternative area was not in ECAD and would require having bought access to ECAD to get at the X/Y coordinates) so it would be much better if the routing keys were more consistent size-wise in terms of number of households - counties and Dublin postal districts would have been good and readily understood.

Anyone have data on purchases of ECAD?

PDVerse · 26-09-2016 07:19AM

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.

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 · 26-09-2016 08:37AM

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.

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.

PDVerse · 26-09-2016 08:48AM

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.

Your point is simply invalid. There are opinions, informed opinions, and expert opinions. To give an example:

Expert Opinion: Climate change is real
Informed Opinion: I'm not a climatologist, but I've studied the statistical data and I have questions.
Opinion: See Danny Healy-Rae

CSO's job is to gather and publish statistics in various formats suitable for their use case. As someone who has worked with their output for 23 years I can assure you they do a very good job. Small Areas were created specifically for CSO to enable more granular statistics below ED level. They DO NOT have a deficiency that they were hoping a postcode design would resolve. The problem you're describing does not exist.

The road from ignorance to knowledge requires honesty. You have to admit that you only have an opinion, and to legitimately argue against expert opinion you have to at least put the work in to be informed.

Sam Russell · 26-09-2016 08:50AM

Mod: Can we get back to discussing the implementation of Eircode. Design of Eircode has its own thread. Thank you.

plodder · 26-09-2016 08:57AM

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.

Sam Russell · 26-09-2016 09:09AM

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.

We need three different threads because one thread would be unable to stop the discussion going down rabbit holes in pursuit of particular posters rehash of well travelled opinions, and other posters well rehearsed rebuff of such opinions, and so on ad infinitum.

With three threads we have new the Google maps story - how is it going; the old Eicode design - good or bad; and the newer Eircode - who's using it now.

I think one thread would be difficult to follow. I may move some design posts from the implementation thread if I have time.

PDVerse · 26-09-2016 09:12AM

Sam Russell wrote: »

Is the decision to use such large routing keys affecting the take up of Eircode for many or specific uses?

The answer to this question is no based on experience of implementations in the following sectors: Delivery and Logistics, Insurance, Retail, Banking, Telecommunications, Local and Regional Government, eCommerce, Sales and Service Engineer Allocation, Broadband Coverage.

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 · 26-09-2016 10:37AM

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.

This tallies with my experience. I simply don't care about routing keys; they're all but irrelevant to my use of Eircodes.

plodder · 26-09-2016 12:07PM

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.

Yes, you've pointed this out many times before, and I don't think anyone has ever disagreed with you.

Sam Russell · 26-09-2016 02:23PM

Mod: I've moved a couple of posts to the design thread where they fit better.

Bray Head · 27-09-2016 01:22PM

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.

Carawaystick · 27-09-2016 04:34PM

Don't the revenue have unique identifiers for lpt? which has to be paid up before a sale goes through

plodder · 27-09-2016 06:36PM

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.

Yes, that is useful

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.

I'm not that familiar with German ones, but the UK postcode tends to have reasonably consistent sizes at the level of area, district, sector and the fact that you have that hierarchy means statistics can be easily combined at one of those levels, without needing to license any database or software. Areas tend to cover population of several hundred thousand. Districts cover tens of thousands and sectors less than ten thousand typically.

Eircode - its implemetation (merged)

Comments