Postcode search depends on arbitrary points, when a postcode is better described as an area

[andrewperry]

Currently the Postcode search in mapit is dependent on uploading postcodes as points, when in reality postcodes cover an area.

It would be preferable if postcodes could also be uploaded as areas, in jurisdictions where this data is available, so that more accurate results can be obtained.

[dracos]

If your jurisdiction holds postcodes as areas, then you can upload and treat them as areas using the existing area code. The fact they're called "areas" and "postcodes" doesn't restrict you from using them as such - "postcodes" could more accurately be called "points" and be used for any pointwise data.

[andrewperry]

Unfortunately we also had to prefix Postcode area names with "pc" to make them non-numeric for now, as when passing MapIt an integer as the "area_name" (ie http://mapit.openlocal.org.au/areas/"area_name"), MapIt will assume that an integer is an Area ID instead, which will give you a different area entirely. I think that ideally there would be a different method for searching by name or id to avoid this, but currently the code is "helpfully" making some assumptions on what is being passed to it based on case (all upper case assumed to be an Area Type vs Area Name prefix) and data type (integers assumed to be IDs not names).

For now, this means that anything relying on the service needs to strip the leading "pc" from results, and add it to queries.

[dracos]

Yes, those "helpful" (and many years old) things certainly won't be, sorry. Certainly there are ways round in some aspects, e.g. see global mapit's http://global.mapit.mysociety.org/code/osm_rel/129836.html for example - using code for the numeric ID of the postcode, perhaps. Then we could have a config option to treat a code as primary rather than the ID, or something similar.

Having separate calls somehow for type/name rather than areas/ guessing on case would certainly be better.

[andrewperry]

MapIt has been very helpful to us quickly being able to visually and programatically interact with various areas, so appreciate all the work that's been done and all the help given! Using the code for the numeric postcode sounds like a plan, will look into it.

[andrewperry]

PS the other thing we looked at was using a language to say that pc6000 was "6000 in English" but that was even hackier!

[andrewperry]

With the quiet launch of a "MapIt Australia" at http://mapit.openlocal.org.au on Australia Day, an enthusiastic developer, Rosie Williams, built a service to take a suburb or postcode and look up the coverlaps (I believe) in MapIt - check it out here:

http://budgetaus.net/postcodes/index.php

Open innovation FTW!

[mlandauer]

Hi @dracos,

Another idea to throw into the mix. What if the canonical urls for the areas were based on the type and name? So, for example http://global.mapit.mysociety.org/area/59139.html would instead be http://global.mapit.mysociety.org/area/O08/Zurich. The advantage of that would be that the url wouldn't be dependent on an internal id and given a know type and name you could just generate the url.

This would address this issue with numeric area names. So, for instance you would look up postcode area 2000 with http://mapit/area/PC/2000

@dracos would you be open to accepting a pull request for either a solution involving a new api call to look up areas by name or this new canonical url approach?

Either of these approaches could be done and still maintain backward compatibility.

[andrewperry]

Another benefit of Matthew's approach is that it would enable the same name to be used by areas of different types without causing a lookup issue.

[mlandauer]

@andrewperry I think you can do that currently with a call like /areas/[name prefix]?type=[type]

[dracos]

You can have two areas with the same name and type, e.g. http://mapit.mysociety.org/area/33721.html and http://mapit.mysociety.org/area/33327.html, or http://global.mapit.mysociety.org/area/509311.html and http://global.mapit.mysociety.org/area/509265.html. In the UK case you could construct some form of hierarchy around parentage, but OSM doesn't have that information, and that's only by assuming things about the nature of the data anyway. The main reason MapIt when it started (back in 2003) didn't use Office for National Statistics identifiers was that they did not produce any identifiers for county council electoral divisions (CED). And it seemed easier to have a flat structure given the contents could be anything :) Areas can also change name over time, and you don't want things using the URL to break due to that.

Your example of postcode area 2000 can already be done with a pretty similar URL - if you import the numeric ID as a code then it's e.g. http://global.mapit.mysociety.org/code/osm_rel/1690227.html (which is looking up by OSM relation ID), so you could have /code/pc/2000 - which redirects to the internal ID page. As I mentioned above, you could potentially add something to optionally treat a code as "primary" in some regard, that could be nice.

I definitely agree it could use a better search than just name-prefix. Providing an argument to fix the areas name lookup call to the "whole name" rather than prefix would be a small addition that might be what you're after? So /name/foo.html?type=bar&whole=1 or something. But perhaps a new /name endpoint would be clearer.

[mlandauer]

Okay. It looks like importing with IDs might be the way to go for now. It doesn't feel nice to me though. Thanks for your help @dracos. This stuff sure is complicated! ;-)

[dracos]

Feature requests here are existing tickets, e.g. #194 #101 so closing.