[OSM-dev] A proposal for linking multiple ways into a virtual polygon

Frederik Ramm frederik at remote.org
Tue May 15 19:32:45 BST 2007


Jon,

> What I'm thinking of is essentially a doubly-linked list pointer in the
> ways. Each way which forms part of a polygon includes the IDs of the
> ways which join on each end, eventually forming a closed loop:

[...]

> Tools like Josm can carry on editing these ways without needing any
> explicit support for these tags. 

Similar proposals - all containing the basic idea that way/segment/node 
ids be used as tag values in other obejcts - have been made for a number 
of other things. They are, of course, all a workaround for the lack of 
object relationships, and they all run the risk of being ruined by a 
tool that is ignorant of these tags (e.g. someone accidentally deleting 
and then reconstructing a way, or someone splitting a way in two with 
JOSM which would retain all tags, etc.)

You know that I don't know a lot about PostGIS and what you're doing in 
your database so forgive me if this is way off the mark. But, given that 
you convert the whole planet file into a relational database with all 
that super GIS stuff and spatial indexing and so on, is it really so 
difficult to do something like - wildly fantasizing pseudo-SQL here:

SELECT w1.id,w2.id FROM ways w1, ways w2 WHERE 
w1.last_node_of_shape=w2.first_node_of_shape AND w1.tags=w2.tags

and then combine these pairs into one linear feature if w1 != w2, or 
make an area feature from them if w1 == w2, and repeat the process until 
none are found?

I can see how something like this would be difficult if one tries do do 
it *while* importing the planet file, but once you have SQL at your 
hands, it sounds as if it should be rather easy, and quick even.

If theoretically working on all 600.000 ways is too much strain on the 
database, we could still introduce a tag saying "mapnik:recombine=true", 
and stick that on every way that should, if possible, be merged with 
adjoining ways.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'




More information about the dev mailing list