Re: [OSM-talk] Missing structure
On Jan 17, 2008 11:00 PM, Lester Caine [EMAIL PROTECTED] wrote: Karl Newman wrote: On Jan 17, 2008 12:52 PM, Lukasz Stelmach [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Lester Caine wrote: After my missive in the postal addresses thread I had yet another scout around on what is already available and how it is not being managed well. All mapping is currently based on physical nodes, but I think that perhaps we need an abstract element that we can hang things on. [...] Day by day it becomes more obvious to me that sooner or later segments/ways distinction will be back with us. Look at this. A way (street) may belong to many relations, right? Each relation may contain different part of the street, right? Especially in big cities where bus routes can be relations and each bus may take different turns, there will bo no single way/highway comprising more than one segment (to be precise I think about lines between crossings which in case of curved street may comprise more segments). There will obviously MUST be invented 'street' replation which takes a few segmetns and gives them common name. The other relation (perish?) could contain all the objects that belong to a certain place including half of the segments of the streets that connects two adjacent places. This shows a little problem which, however, should be automatable, a new object (node/way|segment) has to be assigned to a different object (relation) rather then assigning the place relation to the new object. I am just shatring my thoughts, maybe someone can come up with some thing wiser ;-) It seems to me we're going about this all wrong. Instead of splitting up ways just because any of its attributes change (or to break it up for a route), it seems like a way which denotes the same street (or other linear feature) should be as long as possible. Then we could hang attributes on subsections of it: i.e., for way 1234, the speed limit from node 5522 to node 5595 is 100 km/h. Or, way 1234 is a part of route blue bus from node 9553 to node 2558. Relations could accomplish this, but they don't have a rigorous structure to enforce all the parts/data integrity. This is missing the point *I* was trying to make and while managing the detail at this lower level IS important, it's the integrity of links to the upper levels that need fixing first. A lot of the higher level relationships could be 'calculated' if we had well established areas and fast searching on geographic position, but in the absence of that, a street, or village 'is_in' a ward, parish, county or other area designation, and these areas are then 'is_in' states or countries. So a simple following of the 'is_in' links provides the hierarchy and the integrity of objects used 'is_in' should be enforced to ensure that there is only one occurrence of the target object ! Just allowing any free format matching does not work! OTHER hierarchy is also appropriate such as 'M1' or 'Ermine Street' but proposing to merge all of the ways associated with them would not work. We do need rules as to how the tagging could be used to identify these sorts of divers structures, and a 'place' called Ermine Street which can then be used in an is_in tag on elements of that road, makes sense, but would distract from identifying the appropriate 'address' for properties on it. Another example is postcode, and a long street that has 4 postcodes SHOULD be four ways ( although there may be several branching ways on some housing estates ) each tagged 'postcode' and is_in 'This street' - it's where the object 'This street' exists that is the problem :( -- Lester Caine - G8HFL Lester, Sorry, I was making more of a general comment about how ways are degrading into segments because of the frequent need to split them. I wasn't really commenting on your proposal. However, I will now. :-) I don't have any particular objections against your proposal (although it is somewhat complex), but I still think geographic boundaries are the way to go. Which do you think will happen first: Creation of boundaries and a way to quickly query a point against them (or rather the reverse: given a point, return the boundaries), or tagging of nearly every object in the database with an is_in tag? Since it is going to be renderers, routers and other data consumers that need that data, there's no need to impose a burden on OSM itself. It could be done as a parallel activity, derived from information in the database, somewhat like the Name Finder. If the boundaries are in the database and appropriately tagged, they could be used for this purpose. Karl ___ talk mailing list talk@openstreetmap.org
Re: [OSM-talk] Missing structure
Martijn van Oosterhout wrote: On Jan 18, 2008 3:42 PM, Karl Newman [EMAIL PROTECTED] wrote: I don't have any particular objections against your proposal (although it is somewhat complex), but I still think geographic boundaries are the way to go. Which do you think will happen first: Creation of boundaries and a way to quickly query a point against them (or rather the reverse: given a point, return the boundaries), or tagging of nearly every object in the database with an is_in tag? FWIW, with the coastline checker being basically done, I'm considering applying the same process to boundaries, a boundary checker. As a side-effect it will produce a shapefile of all the boundaries, which can be efficiently queried for is_in-ness... The problem will be checking every boundary found near the object being inspected, which requires all of those boundaries to be complete and closed. Working against an is_in key eliminates all of that processing when trying to find things and will work for boundaries for which the boundary data is incomplete. At some point in the future the is_in keys could be automatically build or corrected when a boundary is edited. However the automatic population would not be able to easily stablish that a particular boundary is within a larger on, at which point the is_in flag for the higher levels become even more important? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Missing structure
On Jan 18, 2008 9:01 AM, Lester Caine [EMAIL PROTECTED] wrote: Martijn van Oosterhout wrote: On Jan 18, 2008 3:42 PM, Karl Newman [EMAIL PROTECTED] wrote: I don't have any particular objections against your proposal (although it is somewhat complex), but I still think geographic boundaries are the way to go. Which do you think will happen first: Creation of boundaries and a way to quickly query a point against them (or rather the reverse: given a point, return the boundaries), or tagging of nearly every object in the database with an is_in tag? FWIW, with the coastline checker being basically done, I'm considering applying the same process to boundaries, a boundary checker. As a side-effect it will produce a shapefile of all the boundaries, which can be efficiently queried for is_in-ness... The problem will be checking every boundary found near the object being inspected, which requires all of those boundaries to be complete and closed. Working against an is_in key eliminates all of that processing when trying to find things and will work for boundaries for which the boundary data is incomplete. At some point in the future the is_in keys could be automatically build or corrected when a boundary is edited. However the automatic population would not be able to easily stablish that a particular boundary is within a larger on, at which point the is_in flag for the higher levels become even more important? -- Lester Caine - G8HFL But Martijn's coastline checker is perfectly suited for checking the completeness of the boundaries. I still maintain that getting correct boundaries and a method to query them are going to be the most expedient path compared to tagging every object inside the boundaries (which would be a maintenance nightmare anyway). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Missing structure
On Jan 18, 2008 3:42 PM, Karl Newman [EMAIL PROTECTED] wrote: I don't have any particular objections against your proposal (although it is somewhat complex), but I still think geographic boundaries are the way to go. Which do you think will happen first: Creation of boundaries and a way to quickly query a point against them (or rather the reverse: given a point, return the boundaries), or tagging of nearly every object in the database with an is_in tag? FWIW, with the coastline checker being basically done, I'm considering applying the same process to boundaries, a boundary checker. As a side-effect it will produce a shapefile of all the boundaries, which can be efficiently queried for is_in-ness... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Missing structure
Lester Caine wrote: After my missive in the postal addresses thread I had yet another scout around on what is already available and how it is not being managed well. All mapping is currently based on physical nodes, but I think that perhaps we need an abstract element that we can hang things on. [...] Day by day it becomes more obvious to me that sooner or later segments/ways distinction will be back with us. Look at this. A way (street) may belong to many relations, right? Each relation may contain different part of the street, right? Especially in big cities where bus routes can be relations and each bus may take different turns, there will bo no single way/highway comprising more than one segment (to be precise I think about lines between crossings which in case of curved street may comprise more segments). There will obviously MUST be invented 'street' replation which takes a few segmetns and gives them common name. The other relation (perish?) could contain all the objects that belong to a certain place including half of the segments of the streets that connects two adjacent places. This shows a little problem which, however, should be automatable, a new object (node/way|segment) has to be assigned to a different object (relation) rather then assigning the place relation to the new object. I am just shatring my thoughts, maybe someone can come up with some thing wiser ;-) -- Było mi bardzo miło. Czwarta pospolita klęska, [...] Łukasz Już nie katolicka lecz złodziejska. (c)PP -- Nadchodzi galaktyczna wojna! Sprawdz http://link.interia.pl/f1ce0 begin:vcard fn;quoted-printable:=C5=81ukasz Stelmach n;quoted-printable:Stelmach;=C5=81ukasz email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Missing structure
Karl Newman wrote: On Jan 17, 2008 12:52 PM, Lukasz Stelmach [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Lester Caine wrote: After my missive in the postal addresses thread I had yet another scout around on what is already available and how it is not being managed well. All mapping is currently based on physical nodes, but I think that perhaps we need an abstract element that we can hang things on. [...] Day by day it becomes more obvious to me that sooner or later segments/ways distinction will be back with us. Look at this. A way (street) may belong to many relations, right? Each relation may contain different part of the street, right? Especially in big cities where bus routes can be relations and each bus may take different turns, there will bo no single way/highway comprising more than one segment (to be precise I think about lines between crossings which in case of curved street may comprise more segments). There will obviously MUST be invented 'street' replation which takes a few segmetns and gives them common name. The other relation (perish?) could contain all the objects that belong to a certain place including half of the segments of the streets that connects two adjacent places. This shows a little problem which, however, should be automatable, a new object (node/way|segment) has to be assigned to a different object (relation) rather then assigning the place relation to the new object. I am just shatring my thoughts, maybe someone can come up with some thing wiser ;-) It seems to me we're going about this all wrong. Instead of splitting up ways just because any of its attributes change (or to break it up for a route), it seems like a way which denotes the same street (or other linear feature) should be as long as possible. Then we could hang attributes on subsections of it: i.e., for way 1234, the speed limit from node 5522 to node 5595 is 100 km/h. Or, way 1234 is a part of route blue bus from node 9553 to node 2558. Relations could accomplish this, but they don't have a rigorous structure to enforce all the parts/data integrity. This is missing the point *I* was trying to make and while managing the detail at this lower level IS important, it's the integrity of links to the upper levels that need fixing first. A lot of the higher level relationships could be 'calculated' if we had well established areas and fast searching on geographic position, but in the absence of that, a street, or village 'is_in' a ward, parish, county or other area designation, and these areas are then 'is_in' states or countries. So a simple following of the 'is_in' links provides the hierarchy and the integrity of objects used 'is_in' should be enforced to ensure that there is only one occurrence of the target object ! Just allowing any free format matching does not work! OTHER hierarchy is also appropriate such as 'M1' or 'Ermine Street' but proposing to merge all of the ways associated with them would not work. We do need rules as to how the tagging could be used to identify these sorts of divers structures, and a 'place' called Ermine Street which can then be used in an is_in tag on elements of that road, makes sense, but would distract from identifying the appropriate 'address' for properties on it. Another example is postcode, and a long street that has 4 postcodes SHOULD be four ways ( although there may be several branching ways on some housing estates ) each tagged 'postcode' and is_in 'This street' - it's where the object 'This street' exists that is the problem :( -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Missing structure
On Sun, 2008-01-13 at 09:40 +, Lester Caine wrote: Taking an example * place=village * name=Ryde * is_in=England, Isle of Wight, Hampshire SHOULD be is_in=Isle of Wight With * place=county * name=Isle of Wight * is_in=Hampshire * place=county * name=Hampshire * is_in=England * place=country * name=England * is_in=United Kingdom I was thinking that stating a hierarchy isn't required. One can be automatically generated from a list of tags at the same level. This is somewhat reminiscent of Epiphany's bookmark handling, where you give your bookmarks tags and it generates a hierarchy based on them. [0] For instance, something could be is_in = East Dunbartonshire, Scotland, UK and another one could be Fife, Scotland, UK. From this, we can infer that there are 2 high level places (Scotland and UK) and 2 low level places (East Dunbartonshire and Fife). [0] http://www.kbs.twi.tudelft.nl/Publications/MSc/2002-Knezu-MSc.html -- Bruce Cowan [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
