[OSM-dev] A proposal for linking multiple ways into a virtual polygon
frederik at remote.org
Tue May 15 19:32:45 BST 2007
> 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
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the dev