[NUUG fiksgatami] [patch] First draft for importing area unions into MapIt

[Petter Reinholdtsen]

[Matthew Somerville]
> I don't mind, but I generally prefer only doing something like that
> when it's proven necessary (the UK does not have such
> administration, for example).

OK.  I suspect it make most sense to give the Norwegian Public Roads
Administration its own area type, and the NRA code seem sensible
enough.

> Generations are to handle if boundaries change/disappear/appear. If
> you're creating new things, it doesn't matter, it's only if you want
> to update a boundary but keep the old one too that you might want to
> use them in some way.

Right.  I believe I understand it now.

Was a bit surprised that the regions "disappeared" when I updated the
kommune and fylke borders and created a new generation, until I
discovered that this was because the regions did not have the new
generation in its generation_high attribute.

> Couple of bugs - it won't work well if two things have the same name
> (it'll just use the first), nor if a name has a "," in it.

Yeah.  Guess I should use area IDs instead, but it make the region
definition harder to write and read.

> You are creating Areas with manual primary IDs; that's not what the
> UK does, we just assign them as things are inserted as we don't have
> IDs to use; so it's not generic in that sense, not that I mind.

I based it on the ID assigments used in import_norway_osm.py, where
the area ID is the number assiged to admin regions in Norway.

I was planning to use very high numbers as IDs for the regions
(organisation numbers from the Norwegian organisation database), but
these numbers are out of range for a 32-bit integer so I have to drop
this idea.  How are the IDs automatically generated for UK?  I suspect
it would be good if the road authority IDs were easy to guess, for
example using IDs 10000001 - 10000005, and start at different offsets
for different type of regions and make sure the IDs are way above the
fylke and kommune IDs.

> Just to record, the other approach as outlined to you previously
> would be to have the PRAs in the Area table, but without any
> Geometry, and alter the code so that whenever a fylke is returned,
> the corresponding road authority is returned as well. That way, if
> the boundary of the fylke changes, you don't need to also change the
> road authority boundaries, plus you don't need to do
> point-in-polygon tests on potentially very large shapes, as the
> P-in-P test on the fylke gives you the information you need.

I decided against such approach because I want my region import script
to handle other kind of regions too without code changes.  I already
see the need for regions for power grid distributors covering several
municipalities (kommune), and expect to run into other similar regions
later.  The best migth be if mapit genericly handled areas defined as
the union of other areas internally, but that code is currently
missing.  I suspect it would require quite a lot of code changes and
database schema changes in mapit.

> http://postgis.refractions.net/docs/ch04.html#id2635061 implies that
> large shapes are bad; if you have no problems, that's fine, but it's
> something to bear in mind that a different approach might be more
> efficient.

Thanks for bringing it to my attention.  I do not see a problem, and I
suspect that is because my areas are a lot smaller than europe. :)

I've created a git branch on githup for this work.  It is available as
<URL: https://github.com/petterreinholdtsen/mapit/tree/area_region >.

Happy hacking,
-- 
Petter Reinholdtsen