Re: [OSM-talk] is_in and similar tags
Could someone[1] setup a web-service where you send it a lat/lon and it returns a list of all boundaries that point is within? So just one website imports the boundary data instead of everyone having to know how to do the 'is within' search[2]. I think you might be able to do this with http://wiki.openstreetmap.org/wiki/OSM_Server_Side_Script Yes. To appeal to [1], replace in the URL (in one line) http://78.46.81.38/api/interpreter?data=%3Ccoord- query%20lat=%2251.0%22%20lon=%227.0%22/%3E%3Cprint%20mode=%22body%22/%3E the values 51.0 (latitude) and 7.0 (longitude) by the respective values. Then save the file to disk and you receive an OSM-alike file with the areas that cover the given location. Another, maybe more convenient way would be (command line in one line) wget -O - --post-data=coord-query lat=\51.0\ lon=\7.0\/print mode=\body\/ http://78.46.81.38/api/interpreter | gunzip The details are explained at http://78.46.81.38/#section.reverse_gazetteer Cheers, Roland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
On 28 Jul 2009, at 13:43, John Smith wrote: Is there a real need for is_in tags or have admin boundaries replaced the need? Admin boundaries are the new way of doing this. The is_in tag was the early way of trying to show a hierarchy of admin areas. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: Admin boundaries are the new way of doing this. The is_in tag was the early way of trying to show a hierarchy of admin areas. Ok, so is_in is redundant. There was talk on the dev list about removing a bunch of tiger tags from nodes. Should other tags also be removed, like is_in that are no longer needed? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
Shaun McDonald wrote: On 28 Jul 2009, at 13:43, John Smith wrote: Is there a real need for is_in tags or have admin boundaries replaced the need? Admin boundaries are the new way of doing this. The is_in tag was the early way of trying to show a hierarchy of admin areas. It is still *very* helpful to have is_in present though. It is much easier to present this information in a search than to do polygon tests which requires a whole new algorithm (desirable though that is), and of course, boundaries are nowhere near complete, and you often know in which region a place is without knowing the exact boundary. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
Perhaps the more appropriate question would be what are appropriate tag keys that could be used in combination with the tag place=*? So far all I can come up with is name and possibly source. I'm primarily only looking at aussie data so I may have over looked things. is_in seems to have already moved to boundary information, as well as post codes, population information and so forth should be shifted to the admin boundaries as well if they haven't already. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote: It is still *very* helpful to have is_in present though. It is much easier to present this information in a search than to do polygon tests which requires a whole new algorithm (desirable though that is), and of course, boundaries are nowhere near complete, and you often know in which region a place is without knowing the exact boundary. Two different issues, one is presentation the other is simply describing something. A lot of software repackages information into it's own optimised form, and so I don't think it's a valid argument to keep the information when processing the information into a suitable presentable form would do the same thing. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
John Smith wrote: --- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote: It is still *very* helpful to have is_in present though. It is much easier to present this information in a search than to do polygon tests which requires a whole new algorithm (desirable though that is), and of course, boundaries are nowhere near complete, and you often know in which region a place is without knowing the exact boundary. Two different issues, one is presentation the other is simply describing something. A lot of software repackages information into it's own optimised form, and so I don't think it's a valid argument to keep the information when processing the information into a suitable presentable form would do the same thing. But until we do, the existing mechanism does no harm, and as I said, you don't always know the boundary while you do know where the place is. Determining the inclusion of every place in the database, even if we had complete information, is massively more complex than simply being told the information. If you have it, why not give it. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
2009/7/28 John Smith delta_foxt...@yahoo.com: Perhaps the more appropriate question would be what are appropriate tag keys that could be used in combination with the tag place=*? So far all I can come up with is name and possibly source. I'm primarily only looking at aussie data so I may have over looked things. A lot of places have population=, ele=, is_in=, is_in:*=, name:*=, official_name:*=, *_name=, wikipedia=, capital=, various types of locations codes (off the top of my head) and most of these seem appropriate. is_in seems to have already moved to boundary information, as well as post codes, population information and so forth should be shifted to the admin boundaries as well if they haven't already. What if boundary is not defined but the hierarchy is defined, such as with post codes? Should people invent boundary polygons based on just what nodes/ways belong to the area? I hope not. This is the case with administrative hierarchy of regions/counties/municipalities in a lot of countries, in other countries there is no and possibly will never be any way to obtain the official boundary polygon information. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote: But until we do, the existing mechanism does no harm, and Apart from massively bloating the database due to massive amounts of redundant and/or useless information that doesn't gain us anything. as I said, you don't always know the boundary while you do know where the place is. That's part of the point of my questions, add the information to boundaries if it exists elsewhere and other general house cleaning, and if it doesn't exist on place tags already it may exist on boundaries so I still think your point isn't valid. Determining the inclusion of every place in the database, even if we had complete information, is massively more complex than simply being told the information. If you have it, why not give it. At this point in time a lot of nodes tagged place=* tags in Australia don't have additional information, those that do seem very inconsistent and would be absolutely useless for any kind of routing engine. I can't speak for anywhere else as I haven't checked node information for anywhere else. What I'm suggesting is a clean up, if that means adding a bunch of tags to nodes so be it, but I doubt that is the best way to go to achieve consistency to be honest. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote: What if boundary is not defined but the hierarchy is defined, such as with post codes? Should people invent boundary polygons based on just what nodes/ways belong to the area? I hope not. Why spend just as much time tagging every node, way and relation in an area with this information, how would that be useful when a rough polygon can essentially tag all those nodes? This is the case with administrative hierarchy of regions/counties/municipalities in a lot of countries, in other countries there is no and possibly will never be any way to obtain the official boundary polygon information. We don't have official information available for most roads in most countries how does that stop unofficial information being added? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
On 28 Jul 2009, at 15:35, John Smith wrote: --- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote: What if boundary is not defined but the hierarchy is defined, such as with post codes? Should people invent boundary polygons based on just what nodes/ways belong to the area? I hope not. Why spend just as much time tagging every node, way and relation in an area with this information, how would that be useful when a rough polygon can essentially tag all those nodes? Only use the is_in tag on the place nodes rather than every node. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
But until we do, the existing mechanism does no harm, and as I said, you don't always know the boundary while you do know where the place is. Determining the inclusion of every place in the database, even if we had complete information, is massively more complex than simply being told the information. If you have it, why not give it. Given that there is currently quite a high probability that some of the boundaries will be wrong (having moved since the NPE maps were published), there's another good reason to have what amounts to essentially duplicated information in the is_in= tag - there will be a number of cases where the two sources will contradict each other. It will then only be a matter of time before someone motivated writes a checker to compare the two and generate a list of errors, then motivated individuals will then check their local area and fix the errors in whichever source is wrong. It worked for coastlines and is working for things like nearly-junctions now - so could work quite well here. (I'm not volunteering to write the checker, but I would certainly be willing to spend time looking at any errors thus detected). Donald ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: Only use the is_in tag on the place nodes rather than every node. Why? The reasoning I've been given so far is for routing, but to find such information routing software would have to look at all nodes near by until it found the node tagged with the place information. The information I've reviewed so far shows at least one airport tagged as a place, and a whole bunch of other information wrong or contradictory or you name it someone has probably done it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, Donald Allwright donald_allwri...@yahoo.com wrote: (I'm not volunteering to write the checker, but I would certainly be willing to spend time looking at any errors thus detected). This came up because I've started writing a checker to find certain tag combinations and one thing I kept seeing over and over again was inconsistent tagging of place=* nodes. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
2009/7/28 John Smith delta_foxt...@yahoo.com: --- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote: What if boundary is not defined but the hierarchy is defined, such as with post codes? Should people invent boundary polygons based on just what nodes/ways belong to the area? I hope not. Why spend just as much time tagging every node, way and relation in an area with this information, how would that be useful when a rough polygon can essentially tag all those nodes? Both for the time spent tagging and space used in database, perhaps there might be some saving from using polygons but it depends on the exact scenario. Either way, don't add the tags you think are of no use, they'll be added by people for whom they're useful. Or easier to make use of than the boundary polygons, particularly for those asking where a place is inside a hierarrchy is_in gives the immediate answer. In the renderer one idea I had was to use the number of commas in the is_in= value to decide on the text size of suburb/district labels in a city (they could be tagged as districts, parishes, etc instead - but you would quickly run out of tags), that's much more complicated with boundary polygons only. This is the case with administrative hierarchy of regions/counties/municipalities in a lot of countries, in other countries there is no and possibly will never be any way to obtain the official boundary polygon information. We don't have official information available for most roads in most countries how does that stop unofficial information being added? Well, that stops us because in this case the unofficial information is taken out of thin air, i.e. wrong. Say someone asks the map: am I in county A or county B at this point? The answer given may have 50% chance of being wrong. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
John Smith wrote: --- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: Only use the is_in tag on the place nodes rather than every node. Why? The reasoning I've been given so far is for routing, but to find such information routing software would have to look at all nodes near by until it found the node tagged with the place information. The reason I gave was for name searching, not routing. It allows the result of a search to be given a descriptive context that isn't currently possible any other way. This already works and it is a shame to break it because of dogma. Given a place (or any other object, but as Shaun said, places are the key things), determining for every place which county, state, country a place is in is complicated and will take a lot of compute resources. It amounts in principle to comparing each point against every boundary polygon in the world. Yes there are optimizations and short cuts, but it will nevertheless be a lot of work to do. And given that places don't move around significantly, we'll want to store the result in order to avoid recomputing it every time - and we have a natural place in which to store it already. We can give ourselves a helping hand here if we keep is_in. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote: Both for the time spent tagging and space used in database, perhaps there might be some saving from using polygons but it depends on the exact scenario. Either way, don't add the tags you I doubt I can agree that using polygons would use more space if you were in turn able to reduce a lot of per node or per way information that would be made less redundant. think are of no use, they'll be added by people for whom they're useful. Or easier to The only people they seem useful for are those making routing software, otherwise I doubt the information is used at all. In the renderer one idea I had was to use the number of commas in the is_in= value to decide on the text size of suburb/district labels in a city (they could be tagged as districts, parishes, etc instead - but you would quickly run out of tags), that's much more complicated with boundary polygons only. That would also require consistent tagging to be useful, which is the crux of the problem, the tagging doesn't appear to be consistent and in turn is less useful. Well, that stops us because in this case the unofficial information is taken out of thin air, i.e. wrong. Say someone asks the map: am I in county A or county B at this point? The answer given may have 50% chance of being wrong. What happens now if information is wrong, someone who does know fixes it. You may not know exact boundaries but people on boundaries know where they usually run. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
John Smith wrote: --- On Tue, 28/7/09, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: Admin boundaries are the new way of doing this. The is_in tag was the early way of trying to show a hierarchy of admin areas. Ok, so is_in is redundant. There was talk on the dev list about removing a bunch of tiger tags from nodes. Should other tags also be removed, like is_in that are no longer needed? We need to be careful about removing tags because it could cause renderers to fail (or at least not work as expected). For example, I think the is_in tag is added after the place name in mkgmap when creating the city POIs. Maybe the solution is to have a list of depreciated tags and maybe give people a year or two to stop using them before they get removed. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote: We can give ourselves a helping hand here if we keep is_in. That's assuming the information contained in it is useful to begin with, as I keep stating the information I've seen is inconsistent so that's not helping any one. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, MarkS o...@redcake.co.uk wrote: We need to be careful about removing tags because it could cause renderers to fail (or at least not work as expected). For example, I think the is_in tag is added after the place name in mkgmap when creating the city POIs. That's fine for existing correct information, what about incorrect or missing ones? :) How's this for consistency, all of these describe various suburbs of Sydney... is_in = New South Wales,Australia name = Surry Hills place = suburb is_in = Australia, NSW, New South Wales, Sydney, Eastern Suburbs name = Elizabeth Bay place = suburb postal_code = 2011 is_in = Australia, NSW, New South Wales, Sydney name = Woolloomooloo place = suburb is_in = Australia, NSW, New South Wales, Sydney, Eastern Suburbs, resort towns name = Bondi Beach place = suburb is_in = Sydney,New South Wales,Australia name = Mascot place = suburb ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
On Tue, Jul 28, 2009 at 4:09 PM, David Earlda...@frankieandshadow.com wrote: The reason I gave was for name searching, not routing. It allows the result of a search to be given a descriptive context that isn't currently possible any other way. It allows the result of a search to be given a descriptive context that isn't currently possible in any other way *that you want to code*. I know you're a strong proponent of the is_in tag, because it makes your life 100 times easier when building the namefinder. That doesn't make it a good idea. What you should really be doing is ask someone to provide, every week, a planet file which has all the is_in tags automatically generated from the polygons, on as many nodes as you find useful. That way the database isn't full of duplicated data, it's easy to edit (c.f. move one boundary vs updating 100,000 is_in tags), mappers don't need to bother with them, bots don't need to fix them, and you don't need to write any code. Maybe some smart cookie could even write an osmosis plugin that does the calculations. Let's stop the is_in debate - yes, they are useful to data consumers, no, they shouldn't be in OSM itself, and no, nobody has yet stepped up to sort it out. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, Andy Allan gravityst...@gmail.com wrote: Let's stop the is_in debate - yes, they are useful to data consumers, no, they shouldn't be in OSM itself, and no, nobody has yet stepped up to sort it out. U I am stepping up to sort it out, at least for some parts of the world, I was just after a little direction on the subject... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
John Smith wrote: --- On Tue, 28/7/09, MarkS o...@redcake.co.uk wrote: We need to be careful about removing tags because it could cause renderers to fail (or at least not work as expected). For example, I think the is_in tag is added after the place name in mkgmap when creating the city POIs. That's fine for existing correct information, what about incorrect or missing ones? :) How's this for consistency, all of these describe various suburbs of Sydney... is_in = New South Wales,Australia name = Surry Hills place = suburb is_in = Australia, NSW, New South Wales, Sydney, Eastern Suburbs name = Elizabeth Bay place = suburb postal_code = 2011 is_in = Australia, NSW, New South Wales, Sydney name = Woolloomooloo place = suburb is_in = Australia, NSW, New South Wales, Sydney, Eastern Suburbs, resort towns name = Bondi Beach place = suburb is_in = Sydney,New South Wales,Australia name = Mascot place = suburb I agree we have a problem and this looks very inconsistent. I like information to be consistent and held only once. The example shows that having a field where you can enter almost anything does result in a variety of inconsistent entries. I'm not against getting rid of is_in, I just think we need to manage the change over a fair period of time to give the renderers a chance to catch up. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
2009/7/28 John Smith delta_foxt...@yahoo.com: --- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote: We can give ourselves a helping hand here if we keep is_in. That's assuming the information contained in it is useful to begin with, as I keep stating the information I've seen is inconsistent so that's not helping any one. Data being wrong is a moot point, it doesn't speak for either is_in tags or boundary polygons and neither help make data more correct really. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote: Data being wrong is a moot point, it doesn't speak for either is_in tags or boundary polygons and neither help make data more correct really. data being stored consistently is the point. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
2009/7/28 Andy Allan gravityst...@gmail.com: Let's stop the is_in debate - yes, they are useful to data consumers, no, they shouldn't be in OSM itself, and no, nobody has yet stepped up to sort it out. One of the two ways to indicate belonging to an area should not be in OSM, agreed. Why's this the is_in tags, is the final rationale the space saving? Take three villages belonging to some kind of administrative division. You may need more than three nodes to draw a boundary that contains only these three nodes and no other nodes. Then it depends on how much space a (repeated three times) tag takes in your particular format compared to space taken by a separate node + the way with a couple of member nodes. Or as a less practical example take two ways that cross one another (one may be a bridge or tunnel), one officially belonging to county A or postcode A and the other to B. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, MarkS o...@redcake.co.uk wrote: I'm not against getting rid of is_in, I just think we need to manage the change over a fair period of time to give the renderers a chance to catch up. It's irrelevant if place nodes don't already have is_in and instead of adding is_in tags we should be instead doing things better. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
Andy Allan wrote: On Tue, Jul 28, 2009 at 4:09 PM, David Earlda...@frankieandshadow.com wrote: The reason I gave was for name searching, not routing. It allows the result of a search to be given a descriptive context that isn't currently possible any other way. It allows the result of a search to be given a descriptive context that isn't currently possible in any other way *that you want to code*. that I want to code *now*. I did say in my first message that polygons were desirable, I just don't want to throw away what we've got until such time as the various solutions and data that have been mentioned are in place. is_in is a pragmatic solution to a problem we haven't *yet* solved another way. I have lots of ideas of things I would like to do with searching which would be vastly easier if we had boundary tests, and as it happens I have been thinking about ways to address this before this debate, so I may well be the person who ends up writing some code to do this. Regarding inconsistency, yes that's a problem for automatic processing (though not insurmountable in most cases, just makes it a bit more complicated). For human readers though its a doddle, and in the case of the Syndey suburbs, at least you can read in a set of search results that this one is in Australia not Canada. If there's errors in them, I don't see the difference between those and any other errors in the map. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
On Tue, Jul 28, 2009 at 5:20 PM, David Earlda...@frankieandshadow.com wrote: Andy Allan wrote: On Tue, Jul 28, 2009 at 4:09 PM, David Earlda...@frankieandshadow.com wrote: The reason I gave was for name searching, not routing. It allows the result of a search to be given a descriptive context that isn't currently possible any other way. It allows the result of a search to be given a descriptive context that isn't currently possible in any other way *that you want to code*. that I want to code *now*. :-) Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
Could someone[1] setup a web-service where you send it a lat/lon and it returns a list of all boundaries that point is within? So just one website imports the boundary data instead of everyone having to know how to do the 'is within' search[2]. Namefinder could then query this to add its own internal is_in tags to the place= nodes as it's importing them. It might also be quite neat for describe my location type things. [1] @lazyosm [2] I assume this is complex, since boundaries aren't guaranteed to contain a single ordered list of nodes? On Tue, Jul 28, 2009 at 2:48 PM, David Earlda...@frankieandshadow.com wrote: Shaun McDonald wrote: On 28 Jul 2009, at 13:43, John Smith wrote: Is there a real need for is_in tags or have admin boundaries replaced the need? Admin boundaries are the new way of doing this. The is_in tag was the early way of trying to show a hierarchy of admin areas. It is still *very* helpful to have is_in present though. It is much easier to present this information in a search than to do polygon tests which requires a whole new algorithm (desirable though that is), and of course, boundaries are nowhere near complete, and you often know in which region a place is without knowing the exact boundary. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
Have a look at boundaries.pl in the wiki -- Urspr. Mitt. -- Betreff: Re: [OSM-talk] is_in and similar tags Von: OJ W ojwli...@googlemail.com Datum: 28.07.2009 19:33 Could someone[1] setup a web-service where you send it a lat/lon and it returns a list of all boundaries that point is within? So just one website imports the boundary data instead of everyone having to know how to do the 'is within' search[2]. Namefinder could then query this to add its own internal is_in tags to the place= nodes as it's importing them. It might also be quite neat for describe my location type things. [1] @lazyosm [2] I assume this is complex, since boundaries aren't guaranteed to contain a single ordered list of nodes? On Tue, Jul 28, 2009 at 2:48 PM, David Earlda...@frankieandshadow.com wrote: Shaun McDonald wrote: On 28 Jul 2009, at 13:43, John Smith wrote: Is there a real need for is_in tags or have admin boundaries replaced the need? Admin boundaries are the new way of doing this. The is_in tag was the early way of trying to show a hierarchy of admin areas. It is still *very* helpful to have is_in present though. It is much easier to present this information in a search than to do polygon tests which requires a whole new algorithm (desirable though that is), and of course, boundaries are nowhere near complete, and you often know in which region a place is without knowing the exact boundary. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
OJ W ojwli...@googlemail.com schrieb: Could someone[1] setup a web-service where you send it a lat/lon and it returns a list of all boundaries that point is within? So just one website imports the boundary data instead of everyone having to know how to do the 'is within' search[2]. I think you might be able to do this with http://wiki.openstreetmap.org/wiki/OSM_Server_Side_Script Cheers, Christoph ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote: If there's errors in them, I don't see the difference between those and any other errors in the map. Maybe someone was trying to do something about error, and maybe it just happened to turn into this debate? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, David Earl da...@frankieandshadow.com wrote: I don't see why you think people entering boundary data will be more consistent than in entering anything else - we have huge inconsistencies all over the place. Our method of tagging encourages it. Because in theory there will be less boundaries then nodes tagged in various ways to indicate the same thing. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote: One of the two ways to indicate belonging to an area should not be in OSM, agreed. Why's this the is_in tags, is the final rationale the space saving? By using boundaries you can effectively tag every node, way and relation with is_in. If you were to tag everything there would be massive amounts of redundancy and wasted space. Take three villages belonging to some kind of administrative division. You may need more than three nodes to draw a boundary that contains only these three nodes and no other nodes. Then it depends on how much space a (repeated three times) tag takes in your particular format compared to space taken by a separate node + the way with a couple of member nodes. You seem to think this is just about place nodes, it's about everything inside a boundary. Or as a less practical example take two ways that cross one another (one may be a bridge or tunnel), one officially belonging to county A or postcode A and the other to B. Exactly, you wouldn't need to split the way, by having a boundary it could be calculated which part would be within which area. At present there is already boundaries for at least countries, some have states and out boundary information. Which is a nice start and so it's not like we're starting from nothing here. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
2009/7/29 John Smith delta_foxt...@yahoo.com: Or as a less practical example take two ways that cross one another (one may be a bridge or tunnel), one officially belonging to county A or postcode A and the other to B. Exactly, you wouldn't need to split the way, by having a boundary it could be calculated which part would be within which area. No no, I wasn't talking about ways crossing a postcode area boundary. Just two ways crossing one another belonging entirely to different divisions each and where do you invent the boundary then. Possibly this is not found in Australia but you'll sometimes find the division of highways into counties is not 100% geographical and postcodes quite often isn't. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] is_in and similar tags
--- On Tue, 28/7/09, andrzej zaborowski balr...@gmail.com wrote: No no, I wasn't talking about ways crossing a postcode area boundary. Just two ways crossing one another belonging entirely to different divisions each and where do you invent the boundary then. Possibly this is not found in Australia but you'll sometimes find the division of highways into counties is not 100% geographical and postcodes quite often isn't. That is a borderline case and the majority of things fall inside one boundary or another. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
