On Jan 17, 2008 11:00 PM, Lester Caine <<a href="mailto:lester@lsces.co.uk">lester@lsces.co.uk</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d">Karl Newman wrote:<br>> On Jan 17, 2008 12:52 PM, Lukasz Stelmach <<a href="mailto:stlman@poczta.fm">stlman@poczta.fm</a><br></div><div><div></div><div class="Wj3C7c">> <mailto:<a href="mailto:stlman@poczta.fm">

stlman@poczta.fm</a>>> 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.

<br>>      ><br>>      > All mapping is currently based on physical nodes, but I think<br>>     that perhaps we<br>>      > need an abstract element that we can hang things on.<br>>     [...]<br>>

<br>><br>>     Day by day it becomes more obvious to me that sooner or later<br>>     segments/ways distinction will be back with us. Look at this.<br>>     A way (street) may belong  to many relations, right? Each relation

<br>>     may contain different part of the street, right? Especially in big<br>>     cities where bus routes can be relations and each bus may take<br>>     different turns, there will bo no single way/highway comprising more

<br>>     than one segment (to be precise I think about lines between<br>>     crossings which in case of curved street may comprise more<br>>     segments). There will obviously MUST be invented 'street' replation

<br>>     which takes a few segmetns and gives them common name. The other<br>>     relation (perish?) could contain all the objects that belong to a<br>>     certain place including half of the segments of the streets that

<br>>     connects two adjacent places.<br>><br>>     This shows a little problem which, however, should be automatable, a<br>>     new object (node/way|segment) has to be assigned to a different<br>>     object (relation) rather then assigning the  place relation to the

<br>>     new object.<br>><br>>     I am just shatring my thoughts, maybe someone can come up with some<br>>     thing wiser ;-)<br>><br>> It seems to me we're going about this all wrong. Instead of splitting up

<br>> ways just because any of its attributes change (or to break it up for a<br>> route), it seems like a way which denotes the same street (or other<br>> linear feature) should be as long as possible. Then we could hang

<br>> attributes on subsections of it: i.e., for way 1234, the speed limit<br>> from node 5522 to node 5595 is 100 km/h. Or, way 1234 is a part of route<br>> "blue bus" from node 9553 to node 2558. Relations could accomplish this,

<br>> but they don't have a rigorous structure to enforce all the parts/data<br>> integrity.<br><br></div></div>This is missing the point *I* was trying to make and while managing the detail<br>at this lower level IS important, it's the integrity of links to the upper

<br>levels that need fixing first.<br><br>A lot of the higher level relationships could be 'calculated' if we had well<br>established areas and fast searching on geographic position, but in the<br>absence of that, a street, or village 'is_in' a ward, parish, county or other

<br>area designation, and these areas are then 'is_in' states or countries.<br><br>So a simple following of the 'is_in' links provides the hierarchy and the<br>integrity of objects used 'is_in' should be enforced to ensure that there is

<br>only one occurrence of the target object ! Just allowing any free format<br>matching does not work!<br><br>OTHER hierarchy is also appropriate such as 'M1' or 'Ermine Street' but<br>proposing to merge all of the ways associated with them would not work. We do

<br>need rules as to how the tagging could be used to identify these sorts of<br>divers structures, and a 'place' called Ermine Street which can then be used<br>in an is_in tag on elements of that road, makes sense, but would distract from

<br>  identifying the appropriate 'address' for properties on it. Another example<br>is postcode, and a long street that has 4 postcodes SHOULD be four ways (<br>although there may be several branching ways on some housing estates ) each

<br>tagged 'postcode' and is_in 'This street' - it's where the object 'This<br>street' exists that is the problem :(<br><div><div></div><div class="Wj3C7c"><br>--<br>Lester Caine - G8HFL<br></div>

</div></blockquote></div><br>Lester,<br><br>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.

<br><br>Karl<br>