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

[Matthew Somerville]

On 02/04/2011 20:51, Petter Reinholdtsen wrote:
> The patch add a new type PRA for this kind of area.  I put the area
> type outside the norwegian types, because I suspect other countries
> have similar roads administration.  Please let me know if this is a
> bad idea.

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

> The import script is tested and found to be working, but the error
> handling is bogus and I have not yet understood the generation stuff.

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.

> The import script is generic, and can combine any existing area into a
> new area, and I expect we will use it here in Norway to create areas
> for power grid distribution areas etc.

> Matthew, please provide your feedback on the approach. :)

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


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.

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.

ATB,
Matthew