Re: [Talk-transit] Naptan import
On 27 Jul 2009, at 22:14, Christoph Böhme wrote: Hi Roger Slevin ro...@slevin.plus.com schrieb: Locality Classification was added as a possible nice to have to the version 2 schema but it has not been populated, and no guidance has been created to indicate how this field should be used (save for a table of permitted values). There is no classification data in NPTG other than that which comes from the source - and that is only there because it could be ... I would not recommend its use as it is flaky, and offers nothing in respect of newly created locality entries in the Gazetteer. So, it looks like we will not have any classification information. Unless we just want to import the plain names this will complicate the import a bit as we have to somehow map the locations to OSM place- types. At the moment I am having three ideas how we could do this: Based on the parent relationship we could guess if a location might be a suburb or village. Many places have wikipedia entries (even villages). If we can manage to automatically look the entries up and extract the relevant information (population size) from the info box we could probably classify a lot of places. The landsat data might give us some hints about the size of places. We just need to find a way to retrieve this information automatically :-) Alternatively we could just invent a value for unclassified places and wait for people to classify the places. It seems that the NPTG data is less useful than it could have been because the the lack of classification data. We do of course also have access to locality names from other sources including NPE maps for places that are more than 50 years old and our eye-balls. Possibly we just provide NPTG data as a useful 'free' data overlay for creating localities in OSM in association with data from NPE but don't spend too long trying to do an automatic import of that data. You mention matching localities up with Wikipedia. I see no licensing issues with using data from Wikipieda as far as I am aware btw. Would be great to tie places up with Wikipedia and possibly also with woeids (http://developer.yahoo.com/geo/geoplanet/) but that could be something for later. Regards, Peter Do you have any other ideas? Cheers, Christoph ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
On 28 Jul 2009, at 18:41, Christoph Böhme wrote: o...@edwardbetts.com schrieb: Christoph Böhme christ...@b3e.net wrote: Many places have wikipedia entries (even villages). If we can manage to automatically look the entries up and extract the relevant information (population size) from the info box we could probably classify a lot of places. I'm afraid we can't use population data, it is under Crown Copyright. I don't know much about the licencing but I find it slightly odd that Wikipedia can distribute its contents under a CC-BY-SA licene when it contains information that is under a more restrictive licence. How am I supposed to know that population numbers are not covered by the CC-BY-SA licence? I don't want to start a huge discussion here about the legal issues of using the population numbers. I'm just curious to learn why Crown Copyrighted data can be in Wikipedia. All information in Wikipedia must be sourced from elsewhere because it must be verifiable. (see http://en.wikipedia.org/wiki/Wikipedia:Verifiability) References should be to reputable sources, such as top newspapers etc. There are guidelines ensuring that copyright material is not used excessively (http://en.wikipedia.org/wiki/Wikipedia:Non-free_content) but in summary it seems that as long as an article is made of information taken from many sources and written for Wikipedia and is not cut and pasted from one source then it has been 'freed'. It is then possible to take information from Wikipedia and reuse it with acknowledgement as per the following: Permission to reproduce and modify text on Wikipedia has already been granted to anyone anywhere by the authors of individual articles as long as such reproduction and modification complies with licensing terms (see below and Wikipedia:Mirrors and forks for specific terms). Images may or may not permit reuse and modification; the conditions for reproduction of each image should be individually checked. The only exceptions are those cases in which editors have violated Wikipedia policy by uploading copyrighted material without authorization, or with copyright licensing terms which are incompatible with those Wikipedia authors have applied to the rest of Wikipedia content. While such material is present on the Wikipedia (before it is detected and removed), it will be a copyright violation to copy it. For permission to use it, one must contact the owner of the copyright of the text or illustration in question; often, but not always, this will be the original author. http://en.wikipedia.org/wiki/Wikipedia:Copyrights Regards, Peter Christoph -- Edward. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
Roger, thank you for your explanations. Roger Slevin ro...@slevin.plus.com schrieb: Although NPTG was originally for public transport purposes, we stressed at all times that a locality should be listed even if it has no public transport - but we know that some local editors have probably erred towards marking some unserved rural hamlets as inactive. All inactive localities should still be in the data - so hamlets which are missing may be in NPTG, but marked as inactive. What would an inactive entry look like in the data? The xml schema does not seem to define any elements/attributes for inactive entries. However they may simply never have been in the source data - and no one to date has recognised the need to add them to NPTG. It would be interesting to see what localities OSM holds in its data which are not included in NPTG (as well as the reverse of this) if that is possible. I created two tables of OSM- and NTPG-only places: http://www.mappa-mercia.org/nptg/nptg-only-localities.csv.gz http://www.mappa-mercia.org/nptg/osm-only-localities.csv.gz I considered a place to be only in one dataset if no place from the other dataset exists in its proximity which has the same name. Proximity was defined as an euclidian distance less than 0.3 between the lat/lon positions of the places (I don't know how this relates to kilometres/miles). Since the OSM data contains some nodes with place-tags that have nothing with actual places, I only included nodes with a place-value of either locality, island, suburb, hamlet, village, municipality, town or city. I also excluded place=farm. Christoph ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
Christoph Sorry - I now realise I shouldn't have referred to inactive localities ... this is something I can see on the editor system for NPTG, but the export only shows the active localities ... the records of the inactive ones are not included in the standard XML file. I would need to check whether it is possible to get an extract from NPTG which includes inactive records (or only comprises the inactive ones) - but that is a question I will only ask if someone can suggest that some useful purpose could be served by having access to that data. Roger -Original Message- From: Christoph Böhme [mailto:christ...@b3e.net] Sent: 28 July 2009 22:54 To: ro...@slevin.plus.com; Public transport/transit/shared taxi related topics Cc: ro...@slevin.plus.com; 'Peter Miller' Subject: Re: [Talk-transit] Naptan import Roger, thank you for your explanations. Roger Slevin ro...@slevin.plus.com schrieb: Although NPTG was originally for public transport purposes, we stressed at all times that a locality should be listed even if it has no public transport - but we know that some local editors have probably erred towards marking some unserved rural hamlets as inactive. All inactive localities should still be in the data - so hamlets which are missing may be in NPTG, but marked as inactive. What would an inactive entry look like in the data? The xml schema does not seem to define any elements/attributes for inactive entries. However they may simply never have been in the source data - and no one to date has recognised the need to add them to NPTG. It would be interesting to see what localities OSM holds in its data which are not included in NPTG (as well as the reverse of this) if that is possible. I created two tables of OSM- and NTPG-only places: http://www.mappa-mercia.org/nptg/nptg-only-localities.csv.gz http://www.mappa-mercia.org/nptg/osm-only-localities.csv.gz I considered a place to be only in one dataset if no place from the other dataset exists in its proximity which has the same name. Proximity was defined as an euclidian distance less than 0.3 between the lat/lon positions of the places (I don't know how this relates to kilometres/miles). Since the OSM data contains some nodes with place-tags that have nothing with actual places, I only included nodes with a place-value of either locality, island, suburb, hamlet, village, municipality, town or city. I also excluded place=farm. Christoph ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
2009/7/26 Christoph Böhme christ...@b3e.net: I am happy to continue working on the NPTG import if Thomas does not mind. Yes, that's fine, NPTG isn't really an interest of mine, as I think I insinuated on the wikipage writeup of the format. 2009/7/27 Peter Miller peter.mil...@itoworld.com: My vote is to get on with it - the NPTG and NaPTAN imports are different enough that they can be handled separately. If Thomas focuses on the NaPTAN import (or hands it over to someone) and you do the NPTG then I think we will get there faster. I am willing to continue. I've just spent the past few days fixing and refactoring the bulk_upload.py script. I just need to write a wrapper for it to simplify the NaPTAN uploads, and we're good to go. Would it be worth creating a NPTG Import wiki page and an NPTG Import user to do the actual import - ie, keep the documentation and audit trail for the two imports separate? So far they're quite closely linked on the wiki, a separate NPTG Import user would probably make sense. 2009/7/22 Peter Miller peter.mil...@itoworld.com: Do we need to set up a wiki page where people can request imports for their authority or are we going to do it without that? http://wiki.openstreetmap.org/wiki/NaPTAN/Request_for_Import I need to flesh out what the column headings mean. -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
On Tue, Jul 28, 2009 at 2:54 AM, Frederik Ramm frede...@remote.org wrote: Hi, Matt Amos wrote: LWG cannot entirely resolve these questions, as they need open discussion and community consensus (which we obviously can't provide on our own). even then, final interpretation is up to the courts. Of course. Thanks for your comments, I especially liked the a(b(X)@c(Y)) part which is a nice structure to think about this. But about my Navteq+OSM example, you said that my reading would be that the deletions from the OSM data are a derivative database of both the OSM data and the navteq data and that the combination of navteq + (OSM - derivative) constitutes a public use of that derivative database, requiring the release of the navteq data. Now if I loaded my Navteq database into postgis and created a buffer around every object, generating one giant buffer area multipolygon for the whole world, then I could use that to subtract data from my OSM data base and would then only have to publish the giant multipolygon under ODbL (because that was mixed with OSM data) and not the original Navteq data. So this means I'd have to get permission from Navteq to release the giant buffer multipolygon under ODbL but if that is granted, I could continue with my OSM-enhanced Navteq tiles plan, and OSM would gain precious little from having access to the Navteq buffer multipolygon. Right? Do you even have to go that far? The Navteq multipolygon isn't actually part of the resulting derivative database, it's just part of the algorithm to get there. Assuming the result is just a shrunk version of the OSM DB I'd have thought the only thing you had to release in this case was the alterations made to the OSM DB -- ie: a list of the bits you deleted. We'd be within our rights to try and reconstruct the multipolygon from those deletions, but you wouldn't have to actually release it? or put another way: if I do o...@navteq = DD (where @ is some function that combines the datasets), there's no circumstance in which I have to release Navteq. My obligation is to release DD under ODbL (I can hand out the DD-OSM diff). This happens to entitle anybody else to attempt to reconstruct as much of Navteq as possible. The ODbL says I have to release changes, it doesn't say I have to tell you why I'm making them. Is that remotely the right reading? Dave ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL: Where do we stand regarding collective/derivative databases
On Tue, Jul 28, 2009 at 9:56 AM, Dave Stubbsosm.l...@randomjunk.co.uk wrote: On Tue, Jul 28, 2009 at 2:54 AM, Frederik Ramm frede...@remote.org wrote: Hi, Matt Amos wrote: LWG cannot entirely resolve these questions, as they need open discussion and community consensus (which we obviously can't provide on our own). even then, final interpretation is up to the courts. Of course. Thanks for your comments, I especially liked the a(b(X)@c(Y)) part which is a nice structure to think about this. But about my Navteq+OSM example, you said that my reading would be that the deletions from the OSM data are a derivative database of both the OSM data and the navteq data and that the combination of navteq + (OSM - derivative) constitutes a public use of that derivative database, requiring the release of the navteq data. Now if I loaded my Navteq database into postgis and created a buffer around every object, generating one giant buffer area multipolygon for the whole world, then I could use that to subtract data from my OSM data base and would then only have to publish the giant multipolygon under ODbL (because that was mixed with OSM data) and not the original Navteq data. So this means I'd have to get permission from Navteq to release the giant buffer multipolygon under ODbL but if that is granted, I could continue with my OSM-enhanced Navteq tiles plan, and OSM would gain precious little from having access to the Navteq buffer multipolygon. Right? Do you even have to go that far? The Navteq multipolygon isn't actually part of the resulting derivative database, it's just part of the algorithm to get there. Assuming the result is just a shrunk version of the OSM DB I'd have thought the only thing you had to release in this case was the alterations made to the OSM DB -- ie: a list of the bits you deleted. We'd be within our rights to try and reconstruct the multipolygon from those deletions, but you wouldn't have to actually release it? or put another way: if I do o...@navteq = DD (where @ is some function that combines the datasets), there's no circumstance in which I have to release Navteq. My obligation is to release DD under ODbL (I can hand out the DD-OSM diff). This happens to entitle anybody else to attempt to reconstruct as much of Navteq as possible. The ODbL says I have to release changes, it doesn't say I have to tell you why I'm making them. Is that remotely the right reading? hmm... i think you may be right. i guess it depends on how it's done. if the merging is done by clipping out OSM data then maybe at most the polygon would need to be released, but maybe not even that. if the merging is done by matching (e.g: roadmatcher) then there's an argument that the database of matches is also a derivative database (which gets used to make the final derivative database) and would require the release of (maybe only some) navteq data... a very specific example may help: if i wanted to take navteq's list of petrol stations and merge it with OSM's - always preferring navteq's then i guess it would be simple to delete those in OSM which are close (fsvo close) to navteq's and then render the two superimposed by method #1. i think this fits your argument above - i can't see any reason why ODbL wouldn't be satisfied by the release of just the deleted items. taking it further, if i wanted to join those petrol stations to a routable network, or put them into a geocoding database... i think you might get away with the geocoding example if, like rendering, your geocoding search was independently performed on both the navteq and OSM lists of points and composited. routing... may be different. i can't, off the top of my head, think of any sensible way to keep the two datasets separate and still useful for those purposes... my head hurts now. cheers, matt ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, Jul 28, 2009 at 3:45 PM, Maarten Deenmd...@xs4all.nl wrote: Having a node shared between a bridge and the way underneath may solve one problem but introduces another (having to make a relation to indicate this physical route is not present). Agreed. maxheight needs to be applied to the road it applies to. Not the structure that is going over it. If you want to do that (which is not that uncommon, water maps do it all the time), introduce another key. Ok. So it seems the question now is, how should maxheight be applied to roads passing under bridges? The only reasonable and maintainable approach, in my opinion, is to apply it to the section of road that is physically under the bridge. Any objections? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
--- On Tue, 28/7/09, Roy Wallace waldo000...@gmail.com wrote: Um...the way would also be close proximity to the bridge, because it passes under it... I don't see how finding a node near a bridge is a particularly elegant solution. And by random I mean the particular node you choose would be arbitrary and in an arbitrary position. And by arbitrary I mean without specific meaning. The solution depends on what problem you are trying to solve, if you are trying to find attributes of a bridge or restrictions of a way, my suggestion solves the restrictions of a way I'm not trying to solve attributes of a bridge. I was referring to the width of the bridge. And sure, A physical attribute like the bridge's full width, which differs to a restriction of maxwidth is just width=* maxwidth exists but I would say that OSM ways are stored as lines. Mathematically, I'm saying a point cannot be under a line, unless it is on it. OSM doesn't store lines, it stores nodes, it stores ways and which nodes are memebers of that way and it stores relations and which ways are members of that relation. You can easily locate any node within a certain radius of any given path (or line) between 2 nodes and do a database lookup which will spit out any results. This is something keep right already checks for so it's not difficult, just processor intensive on a large scale. If you want to be really picky about this you have to remember that even straight lines aren't straight as we're talking about a curved surface of a sphere so if it's straight on a 2 dimensional plane then it would be curved on a spherical one and vice versa. :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
--- On Tue, 28/7/09, Roy Wallace waldo000...@gmail.com wrote: I'm starting to like this idea. But the problem with this is how to define that section of way, so as not to introduce a maintenance You really don't want to pull on that thread, the same can be said for bridges or virtually any other reason a way is split, someone even made a comment about maxspeed splitting ways the other week. It's a much bigger discussion than maxheight and one that probably should be addressed and you would need to attack it as an overall problem, not just for one issue. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
Roy Wallace wrote: On Tue, Jul 28, 2009 at 3:45 PM, Maarten Deenmd...@xs4all.nl wrote: Having a node shared between a bridge and the way underneath may solve one problem but introduces another (having to make a relation to indicate this physical route is not present). Agreed. maxheight needs to be applied to the road it applies to. Not the structure that is going over it. If you want to do that (which is not that uncommon, water maps do it all the time), introduce another key. Ok. So it seems the question now is, how should maxheight be applied to roads passing under bridges? The only reasonable and maintainable approach, in my opinion, is to apply it to the section of road that is physically under the bridge. Any objections? IMHO it is not that important if the way with the limit is only just beneath the bridge, or is somewhat longer or is applied to nodes on either side of a bridge. I recently came across this example where the way with the maxheight is a lot longer than strictly necessary. For every day uses this does not really pose a problem. http://www.openstreetmap.org/browse/way/25883025 Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, Jul 28, 2009 at 3:58 PM, John Smithdelta_foxt...@yahoo.com wrote: --- On Tue, 28/7/09, Roy Wallace waldo000...@gmail.com wrote: The solution depends on what problem you are trying to solve, if you are trying to find attributes of a bridge or restrictions of a way, my suggestion solves the restrictions of a way I'm not trying to solve attributes of a bridge. Well, if possible we should try and find a solution that solves both problems. However, thus far this doesn't seem possible, and the consensus does seem to be that restrictions of a way is of higher priority. But even for that, putting a node in an arbitrary location on a way still seems inelegant to me. OSM doesn't store lines, it stores nodes, it stores ways and which nodes are memebers of that way and it stores relations and which ways are members of that relation. A segment of a way is clearly a line between two points (nodes), without inherent width (sure, it may be specified with width=*, but it's not an inherent property of a way). Anyway, this is off topic. What do you think of my suggestion? That the restriction should be applied to the section of the way that is indeed physically *under* the bridge? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxheight/height
On Tue, 28 Jul 2009 00:22:54 +0200, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: I do not agree that they bouth should be treated as maxheight=* If my car with load that is 3m high, and maxheight=3m, but physical clearance is much higher,than you would pass at the speed limit, but if both maxheight and physical clearance is 3m, than I would need to slow down to almost crawl when passing the lowest point. maxheight can be 3m even if physical clearnance is 3.2m I am not using maxheight in any of the metrics that involve a travel-time to optimize for so it has no effect on the route other then allowing or disallowing that path at all. Thus at least for me it makes no difference. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, Jul 28, 2009 at 4:17 PM, Maarten Deenmd...@xs4all.nl wrote: IMHO it is not that important if the way with the limit is only just beneath the bridge, or is somewhat longer or is applied to nodes on either side of a bridge. I recently came across this example where the way with the maxheight is a lot longer than strictly necessary. For every day uses this does not really pose a problem. http://www.openstreetmap.org/browse/way/25883025 So the solution is do whatever you want? Hrmm... A couple of potential problems with this: What if someone later adds a way that intersects the way with the restriction? The restriction must then be removed from the part of the way that is beyond the bridge - but this user should not be expected to know that the restriction even exists... Also, for longer sections, it becomes less clear that the maxheight restriction is in regard to the bridge (versus the law, power lines, trees, buildings, or something else). For ways with multiple bridges in close proximity, it may become unclear which bridge the restriction applies to. etc etc... It gets a bit sloppy... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
Roy Wallace wrote: On Tue, Jul 28, 2009 at 4:17 PM, Maarten Deenmd...@xs4all.nl wrote: IMHO it is not that important if the way with the limit is only just beneath the bridge, or is somewhat longer or is applied to nodes on either side of a bridge. I recently came across this example where the way with the maxheight is a lot longer than strictly necessary. For every day uses this does not really pose a problem. http://www.openstreetmap.org/browse/way/25883025 So the solution is do whatever you want? Hrmm... A couple of potential problems with this: What if someone later adds a way that intersects the way with the restriction? The restriction must then be removed from the part of the way that is beyond the bridge - but this user should not be expected to know that the restriction even exists... Also, for longer sections, it becomes less clear that the maxheight restriction is in regard to the bridge (versus the law, power lines, trees, buildings, or something else). For ways with multiple bridges in close proximity, it may become unclear which bridge the restriction applies to. etc etc... It gets a bit sloppy... You are right. It is better to stay close around the limiting object. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
Maarten Deenmd...@xs4all.nl wrote: I recently came across this example where the way with the maxheight is a lot longer than strictly necessary. For every day uses this does not really pose a problem. Roy Wallace waldo000...@gmail.com wrote: A couple of potential problems with this: What if someone later adds a way that intersects the way with the restriction? The restriction must then be removed from the part of the way that is beyond the bridge - but this user should not be expected to know that the restriction even exists... This is self evident - we map what is on the ground, and we apply the restriction to the section of the way for which the restriction applies. If a service road for a carpark has a restriction for the entire carpark, even if it is just caused by the danger associated with one or two low-hanging sprinklers, or a pipe, the restriction applies to the entire service road, and not just directly under the sprinklers. If a motorway has a restriction for a motorway section, because of a low bridge, the restriction applies to the section. A higher vehicle is not permitted on that motorway section. If a country lane has a low bridge, the restriction usually only applies to the road section under the bridge, a higher vehicle is usually unrestricted except when it passes the bridge. Applying a restriction to a way where there isn't a restriction, is clearly an error, and should be corrected by the next OSMer to pass that way. Ian. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, Jul 28, 2009 at 08:11:21AM +1000, Roy Wallace wrote: There are two issues here: 1) what should be tagged and 2) what should it be tagged with. For 1), what should be tagged? Definitely the bridge. For two reasons: firstly, clearance under a bridge is an attribute of the bridge. What of bridges that cross multiple ways of different heights? Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, 28 Jul 2009 08:11:21 +1000, Roy Wallace waldo000...@gmail.com wrote: On Mon, Jul 27, 2009 at 9:47 PM, John Smithdelta_foxt...@yahoo.com wrote: --- On Mon, 27/7/09, Roy Wallace waldo000...@gmail.com wrote: I think the bridge should be tagged. There was an overwhelming response on the main talk list that this be tagged as maxheight on the way that has the restriction, ie you can't go under the bridge unless you are under x metres. There are two issues here: 1) what should be tagged and 2) what should it be tagged with. For 1), what should be tagged? Definitely the bridge. For two reasons: firstly, clearance under a bridge is an attribute of the bridge. Wrong. It is an attribute of the ways below the bridge. because: 1) Multiple ways below a round bridge have different maxheight-values (happens in my place all the time) 2) Not only bridges have maxheight but also parking-lots, tunnels, ... 3) The way below the bridge does not intersect the bridge at all. There is no reference from the street below to indicate that there is a bridge at all. You would have to analyse the location and vector of all other ways in the map as one of them could be a bridge and you would have to do that for each and any way-segment you want to evaluate for routing. Bad idea. For 2), what should it be tagged with? I concede that a bridge tagged with height could be misinterpreted (as the actual height of the bridge or bridge construction), as could maxheight (as referring to a restriction involved with traveling on top of the bridge). We have tags maxheight, maxwidth, maxspeed, ... ele and height that are in wide use and have a well established meaning, well documented in the wiki. Period. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, Jul 28, 2009 at 08:01:45AM +0100, Simon Ward wrote: What of bridges that cross multiple ways of different heights? Sorry. I see that this has been commented on elsewhere in the thread. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
On Tue, Jul 28, 2009 at 5:22 AM, Aleksejs Mjaliksli...@keeper.lv wrote: Does OSM invalidates GPS data after some time? Otherwise, roads continuously changes and after we will have a big cloud of points that don't make any sense. No, it doesn't. GPX tracks stay where they are forever and continue being served by the GPS API. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
On Tue, Jul 28, 2009 at 09:21, Ævar Arnfjörð Bjarmasonava...@gmail.com wrote: Does OSM invalidates GPS data after some time? Otherwise, roads continuously changes and after we will have a big cloud of points that don't make any sense. No, it doesn't. GPX tracks stay where they are forever and continue being served by the GPS API. anyway this is something that we might need to consider in the future. GPS are becoming more precise. older tracks are, on a general basis, less precise than actual ones. and road modifications will become more apparent as we progress. -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
Simone Cortesi wrote: On Tue, Jul 28, 2009 at 09:21, Ævar Arnfjörð Bjarmasonava...@gmail.com wrote: Does OSM invalidates GPS data after some time? Otherwise, roads continuously changes and after we will have a big cloud of points that don't make any sense. No, it doesn't. GPX tracks stay where they are forever and continue being served by the GPS API. anyway this is something that we might need to consider in the future. GPS are becoming more precise. older tracks are, on a general basis, less precise than actual ones. and road modifications will become more apparent as we progress. But there is no way to determine if a particular GPS track is outdated. Sure, you can look at the map and say I don't see a physical road for this track, but how would you identify GPS points of a track that is invalid? Especialy for the anonymous tracks? Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
--- On Tue, 28/7/09, marcus.wolsc...@googlemail.com marcus.wolsc...@googlemail.com wrote: 2) Not only bridges have maxheight but also parking-lots, tunnels, ... and trees even if they aren't explicitly signed. http://www.mirror.co.uk/news/top-stories/2008/05/20/shocked-witnesses-describe-horror-bus-smash-115875-20423991/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
On Tue, 28 Jul 2009, Simone Cortesi wrote: Does OSM invalidates GPS data after some time? Otherwise, roads continuously changes and after we will have a big cloud of points that don't make any sense. No, it doesn't. GPX tracks stay where they are forever and continue being served by the GPS API. anyway this is something that we might need to consider in the future. GPS are becoming more precise. older tracks are, on a general basis, less precise than actual ones. and road modifications will become more apparent as we progress. please , don't drop data for many areas we are lucky to have one trace and it may be a year or more before another mapper goes back there consider having access to older data in separate sets if there is concern about using old gps tracks, just don't drop any because it is old (like some of us) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
--- On Tue, 28/7/09, Maarten Deen md...@xs4all.nl wrote: But there is no way to determine if a particular GPS track is outdated. Sure, you can look at the map and say I don't see a physical road for this track, but how would you identify GPS points of a track that is invalid? Especialy for the anonymous tracks? date they were added to the system? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
--- On Tue, 28/7/09, Liz ed...@billiau.net wrote: please , don't drop data for many areas we are lucky to have one trace and it may be a year or more before another mapper goes back there consider having access to older data in separate sets if there is concern about using old gps tracks, just don't drop any because it is old (like some of us) Maybe the best option is to let people stipulate how many traces they want and then download them in reverse order based on data submitted. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
--- On Tue, 28/7/09, Simone Cortesi sim...@cortesi.com wrote: GPS are becoming more precise. older tracks are, on a general basis, You can't make assumptions of the quality of the data based simply on how recently it was added, someone might be using an old piece of GPS kit they were given as a hand me down. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
--- On Tue, 28/7/09, Roy Wallace waldo000...@gmail.com wrote: For maxspeed (your example), the restriction should be applied to the Exactly, you may have to break a way up to apply maxspeed tags to several different parts of what was originally a single way. Exactly the same as a bridge, it is part of longer way but needs to be broken up to indicate the start/end of the bridge etc etc etc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
This doesn't make sense to me. At least there should be a timestamp of gpx-files which tells us when they've been uploaded so that one could filter them a la show me gpx-files not older than 3 years ! Roman On Tue, Jul 28, 2009 at 5:22 AM, Aleksejs Mjaliksli...@keeper.lv wrote: Does OSM invalidates GPS data after some time? Otherwise, roads continuously changes and after we will have a big cloud of points that don't make any sense. No, it doesn't. GPX tracks stay where they are forever and continue being served by the GPS API. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
On Tue, Jul 28, 2009 at 09:59, John Smithdelta_foxt...@yahoo.com wrote: --- On Tue, 28/7/09, Simone Cortesi sim...@cortesi.com wrote: GPS are becoming more precise. older tracks are, on a general basis, You can't make assumptions of the quality of the data based simply on how recently it was added, someone might be using an old piece of GPS kit they were given as a hand me down. I'm talking in the long run. Not something to be done in the coming moths. Still we are just 5 years old. And not many roads did change shape in this short period of time. -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
On Tue, Jul 28, 2009 at 09:58, John Smithdelta_foxt...@yahoo.com wrote: consider having access to older data in separate sets if there is concern about using old gps tracks, just don't drop any because it is old (like some of us) Maybe the best option is to let people stipulate how many traces they want and then download them in reverse order based on data submitted. and/or depending on density of GPSdata in that area. we still have HDOP and VDOP data that (if present) is not being used to spit out accuracy information. -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
Hello ! One think I think it can be useful is a tool for editing all our old trace : - easy to download all our trace - easy to remove unprecise segment (in some old my trace I have some segment who is 50 m wrong !) - easy to simplify them - easy to re-upload modified trace ! I think that a tool like it can be greatly improve the quality of traces. CU Stéphane Liz a écrit : On Tue, 28 Jul 2009, Simone Cortesi wrote: Does OSM invalidates GPS data after some time? Otherwise, roads continuously changes and after we will have a big cloud of points that don't make any sense. No, it doesn't. GPX tracks stay where they are forever and continue being served by the GPS API. anyway this is something that we might need to consider in the future. GPS are becoming more precise. older tracks are, on a general basis, less precise than actual ones. and road modifications will become more apparent as we progress. please , don't drop data for many areas we are lucky to have one trace and it may be a year or more before another mapper goes back there consider having access to older data in separate sets if there is concern about using old gps tracks, just don't drop any because it is old (like some of us) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
--- On Tue, 28/7/09, Simone Cortesi sim...@cortesi.com wrote: I'm talking in the long run. Not something to be done in the coming moths. Still we are just 5 years old. And not many roads did change shape in this short period of time. Some areas have lots of road duplication construction within 5 years of time. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
John Smith wrote: --- On Tue, 28/7/09, Maarten Deen md...@xs4all.nl wrote: But there is no way to determine if a particular GPS track is outdated. Sure, you can look at the map and say I don't see a physical road for this track, but how would you identify GPS points of a track that is invalid? Especialy for the anonymous tracks? date they were added to the system? That is not indicative. A road could remain unchanged for the last 100 years or could have been demolished last year. What would be the expiration time of a track? And would you be prepared to lose correct GPS data to do this? Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
--- On Tue, 28/7/09, Maarten Deen md...@xs4all.nl wrote: That is not indicative. A road could remain unchanged for the last 100 years or could have been demolished last year. What would be the expiration time of a track? And would you be prepared to lose correct GPS data to do this? Also as Liz put, some areas have very few traces so removing based on age is generally a bad idea, where as software specifying fewer tracks to show only the most recent might be the best way to handle it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxheight/height
On Tue, 28 Jul 2009 08:25:34 +0200, marcus.wolsc...@googlemail.com wrote: On Tue, 28 Jul 2009 00:22:54 +0200, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: I do not agree that they bouth should be treated as maxheight=* If my car with load that is 3m high, and maxheight=3m, but physical clearance is much higher,than you would pass at the speed limit, but if both maxheight and physical clearance is 3m, than I would need to slow down to almost crawl when passing the lowest point. maxheight can be 3m even if physical clearnance is 3.2m I am not using maxheight in any of the metrics that involve a travel-time to optimize for so it has no effect on the route other then allowing or disallowing that path at all. Thus at least for me it makes no difference. Marcus It makes no difference for your routing software, but maybe I will make a routing software with that option? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Results from the first Vietnamese Mapping Party last 18th July
Hi everyone, We are really sorry for being late to send u the result of Mapping Party on last 18th July: http://wiki.openstreetmap.org/wiki/HanoiMappingParty2009 Around 15 people assisted to the conferences and to the party, with 5 GPS they divided themselves into 5 groups of 3 people each. On behalf of the party's organization, thank you very much for those who attended and recorded all the data during 2 hours in the hot weather as well as the pollution of Ha Noi's roads. You can check out some pictures about our activity on that day here: http://tinyurl.com/OSMparty1 http://tinyurl.com/OSMparty2 http://www.facebook.com/album.php?aid=92438id=536733262l=bf006cf891 Also here you'll find videos of the presentations: http://hanoi.centre-linux.org/article.php3?id_article=108 Aaron Straut from Flickr helped us after the StateOfTheMap2009 (probably after attending to *The State of Vietnamhttp://www.slideshare.net/khanhlnq/state-of-vietnampresentation) and he added in FLICKR * Vietnam http://www.flickr.com/places/vietnam/, the OSM tiles for Ha Noihttp://www.flickr.com/map?place_id=L.CstOiYA5_7VNSt and Ho Chi Minh City http://www.flickr.com/map?place_id=3wLzgz6YA5ns4Pn0 We are now thinking to make another Mapping Party this time in Ho Chi Minh City, and attract more people, and learn from our mistakes, experience, etc. After the meeting, the number of people update information on OSM has increased rapidly. There are more streets and POI points (useful spots: restaurants, hotels, hospitals,...) have updated. You can check out the results of your own contribution here: http://osm.org/go/4dterHJI- There is one more interesting thing, one third of the participants on that day were female ;) Right now, we still have a bit of the budget and GPS. If anyone has some spare time and loves mapping, please contact us here: Lê Viết Thanh Email: lethanh...@gmail.com Vietnamese Cell: 0984.468.147 Or you can participate in the Vietnamese OSM community (operating by mailing list) at http://lists.openstreetmap.org/listinfo/talk-vi to get helped as well as exchange all the matters about OSM Regards, Ivan Garcia, OSM Mapper ;) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On Tue, Jul 28, 2009 at 09:07:56AM +0200, marcus.wolsc...@googlemail.com wrote: The way below the bridge does not intersect the bridge at all. There is no reference from the street below to indicate that there is a bridge at all. You would have to analyse the location and vector of all other ways in the map as one of them could be a bridge and you would have to do that for each and any way-segment you want to evaluate for routing. Bad idea. I think this is the best reason I've read to tag the street below. I wouldn't want my poor Neo Freerunner to perform queries like this just for some routing. Markus sketches a little too grim image, as a good data structure will prevent you from having to iterate all segments, but still his point is valid. Cheers, -- Sybren Stüvel http://stuvel.eu/ http://www.flickr.com/photos/sybrenstuvel signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Old GPS Data
Sorry to break the threading,
Maybe it's an idea to allow users to specify an area where traces are outdated?
So when a junction is reconstructed a local user can place a bounding
box over that junction and all GPS points in that box are marked as
outdated (or deleted, or whatever). Maybe some extra safety needs to
be made by only allowing users active in the specific area to do this,
or only users who upload traces.
I can think of a few places in my immediate area where the older
('wrong') traces have the upper hand.
Rene.
Maarten Deen:
Simone Cortesi wrote:
On Tue, Jul 28, 2009 at 09:21, ?var Arnfj?r? Bjarmasonava...@gmail.com
wrote:
Does OSM invalidates GPS data after some time? Otherwise, roads
continuously changes and after we will have a big cloud of points that
don't make any sense.
No, it doesn't. GPX tracks stay where they are forever and continue
being served by the GPS API.
anyway this is something that we might need to consider in the future.
GPS are becoming more precise. older tracks are, on a general basis,
less precise than actual ones. and road modifications will become more
apparent as we progress.
But there is no way to determine if a particular GPS track is outdated. Sure,
you can look at the map and say I don't see a physical road for this track,
but how would you identify GPS points of a track that is invalid? Especialy
for the anonymous tracks?
Maarten
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - information
--- On Tue, 28/7/09, André Riedel riedel.an...@gmail.com wrote: What about those information offices that exist on estates where they try and sell you a block of land and/or a house, sometimes a demo house is used as an office, but I've seen little shacks put up as well. Because of information=* is a child of tourism=information, this houses would be better fit in the shop category. Not all informational signs are tourism based, eg directory signs in a multilevel shopping centre complex, another shop thing I guess. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS Data
--- On Tue, 28/7/09, René Affourtit raffour...@gmail.com wrote:
Maybe it's an idea to allow users to specify an area where
traces are outdated?
So when a junction is reconstructed a local user can place
a bounding
box over that junction and all GPS points in that box are
marked as
outdated (or deleted, or whatever). Maybe some extra safety
needs to
be made by only allowing users active in the specific area
to do this,
or only users who upload traces.
I can think of a few places in my immediate area where the
older
('wrong') traces have the upper hand.
I don't know what the right solution is, I've seen people mark ways in OSM to
show what is old ways along side new ways and I can only assume they did this
to prevent old traces from being used to draw ways.
However getting into who should and shouldn't remove GPS traces is going to be
a very interesting topic in and off itself which I don't have a solution to
either.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxheight/height
On Tue, 28 Jul 2009 10:27:52 +0200, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: I am not using maxheight in any of the metrics that involve a travel-time to optimize for so it has no effect on the route other then allowing or disallowing that path at all. Thus at least for me it makes no difference. Marcus It makes no difference for your routing software, but maybe I will make a routing software with that option? You don't need to. You may write just the metric and deploy it as a plugin (1 class and 1 xml-file, that's all that is required). It's simple. I'm looking forward to your rule. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Important radio frequencies was: [tagging] Feature Proposal - RFC - information
2009/7/26 Elizabeth Dodd ed...@billiau.net: Can you suggest how I would map the sign Tourist Radio 88.1 which gives the frequency to tune your FM receiver for the information I am not sure that a sign would help us. But it could be interested if we have tag with important radio frequencies of an area or especially of a tunnel. Radio with actual trafic information often found at the beginning of a tunnel radio:traffic = 92.4 MHz Toursit radio radio:tourist = 88.1 MHz Ciao André ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Important radio frequencies was: [tagging] Feature Proposal - RFC - information
--- On Tue, 28/7/09, André Riedel riedel.an...@gmail.com wrote: Radio with actual trafic information often found at the beginning of a tunnel radio:traffic = 92.4 MHz Some tunnels broadcast across the entire FM radio range if there is accidents and instructions to motorists. Not sure about AM, possibly that too. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Important radio frequencies was: [tagging] Feature Proposal - RFC - information
John Smith schreef: --- On Tue, 28/7/09, André Riedel riedel.an...@gmail.com wrote: Radio with actual trafic information often found at the beginning of a tunnel radio:traffic = 92.4 MHz Some tunnels broadcast across the entire FM radio range if there is accidents and instructions to motorists. Not sure about AM, possibly that too. You can find freqs for some of these tx on: http://users.fulladsl.be/~spb13810/ukweu/F/index.htm Try other countries too... You can fetch a complete list of tx locations/ with or without lon/lat somewhere... For FM, dvbt, am, lw, sw , dab .. Do you want that?? Marc -- Shortwave transmissions in English, Francais, Deutsch, Suid-Afrikaans, Urdu, Cantonese, Greek, Spanish, Portuguese, ... http://users.fulladsl.be/spb13810/radio/swlist/ Stations list: http://users.fulladsl.be/spb13810/radio/txlist/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Thoughts on an enhanced GPX api
On Tue, Jul 28, 2009 at 9:04 AM, René Affourtitraffour...@gmail.com wrote: Sorry to break the threading I can break threading too! So when a junction is reconstructed a local user can place a bounding box over that junction and all GPS points in that box are marked as outdated (or deleted, or whatever). Maybe some extra safety needs to be made by only allowing users active in the specific area to do this, or only users who upload traces. The problem with this is that it's a broken solution to an already limited system. We shouldn't have to /remove/ GPS tracks depending on age, but rather have the ability to mark segments or points of them as trusted (amongst other things). The current schema that we have is: * User uploads a GPX track * Nobody can delete or edit that GPX track (e.g. add additional metadata / delete useless sections) except the user * All GPX tracks are parsed for their points and you can download this giant point cloud given a bbox (see http://wiki.openstreetmap.org/wiki/0.6#GPS_Traces) One problem with this is - as has been observed - that the data gets less useful for everyone as more traces are uploaded. We can devise hacky solutions to this such as not serving old traces via the API. But that's just a lame workaround which'll remove a lot of valid tracesi E.g. I've surveyed footways that have been there for centuries, and probably aren't going anywhere soon. What if the GPX API worked like this instead: * User uploads a GPX track Like now. * All the data is losslessly inserted into the database This means that we can get waypoint/segment/time/ele/whatever data out again. It would probably be simplest to do this by having additional tables equivalent to the node/way tables where a GPX trkseg would be a way, waypoints nodes and so on. * The data is versioned, and anyone can edit it I have a lot of GPX tracks that could be improved, e.g. by deleting point clouds. I'd like to edit them using normal OSM tools, have those edits versioned (so they can be rolled back), and have other users do those fixes for me. Just like with the OSM data I upload. * Users can download GPX traces: ** As a point cloud within a bbox Like now. ** As all tracks within bbox So that tracks can be distinguished (and hidden) and their metadata read edited. ** Using other methods E.g. all tracks by user Then, instead of deleting traces they (or their segments/points) could simply be tagged indicating their subjective quality using a free-form tagging system. You could then just set your editor to ignore those traces. Free-form tags could obviously be used for other purposes, e.g. marking the trace as surveyed with a given GPS model. Implementing this would require new tables in the database, optional changes to all editors (since they could keep using /trackpoints), and new database tables to track GPX data and its history. How does this sound? I'm pretty happy with the 0.6 API except for the GPS bits. I'd like to make GPX a first-class object in OSM and would be willing to hack the rails port to make that happen (when I have time). Is anyone else interested in being able to do what I've described above? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thoughts on an enhanced GPX api
--- On Tue, 28/7/09, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: * The data is versioned, and anyone can edit it I have a lot of GPX tracks that could be improved, e.g. by deleting I'd say deleting sections, but not editing... Only very erroneous information should be touched up by deleting information. point clouds. I'd like to edit them using normal OSM tools, have those edits versioned (so they can be rolled back), and have other users do those fixes for me. Just like with the OSM data I upload. Who can roll back changes, this is ongoing with the OSM data itself, at least in this case it won't effect changes with anything else. Free-form tags could obviously be used for other purposes, e.g. marking the trace as surveyed with a given GPS model. This would be a good idea regardless, as would exposing other meta data already being stored. How does this sound? I'm pretty happy with the 0.6 API Sounds like a good start but some of the finer points probably need to be fleshed out a little more. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thoughts on an enhanced GPX api
On Tue, Jul 28, 2009 at 10:49 AM, John Smithdelta_foxt...@yahoo.com wrote: --- On Tue, 28/7/09, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: * The data is versioned, and anyone can edit it I have a lot of GPX tracks that could be improved, e.g. by deleting I'd say deleting sections, but not editing... Only very erroneous information should be touched up by deleting information. Waypoint names descriptions for one are something that makes sense to edit. When I'm out surveying I use cryptic abbreviations like ohtup for on highway=track unpaved. I'd like to mass-edit my tracks to expand such abbreviations later through an API. But in any case the API supporting editing of an object doesn't mean that it /should/ be edited. With full editing allowed we'd still have version history and could simply revert edits that were inappropriate, just like with the rest of the data. point clouds. I'd like to edit them using normal OSM tools, have those edits versioned (so they can be rolled back), and have other users do those fixes for me. Just like with the OSM data I upload. Who can roll back changes, this is ongoing with the OSM data itself, at least in this case it won't effect changes with anything else. Anyone. Why not? Free-form tags could obviously be used for other purposes, e.g. marking the trace as surveyed with a given GPS model. This would be a good idea regardless, as would exposing other meta data already being stored. How does this sound? I'm pretty happy with the 0.6 API Sounds like a good start but some of the finer points probably need to be fleshed out a little more. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Important radio frequencies was: [tagging] Feature Proposal - RFC - information
André Riedel schreef: I am not sure that a sign would help us. But it could be interested if we have tag with important  radio frequencies of an area or especially of a tunnel. Radio with actual trafic information often found at the beginning of a tunnel radio:traffic = 92.4 MHz I have the spectra for the fm, dab, dvtb broadcasts. For fm, find them here, although I'm not sure if they're 100% ok, I know the source of this data: 20.000 Fm stations all over EU. http://users.fulladsl.be/~spb13810/research/loc.tar.bz2 the data source: http://www.bundesnetzagentur.de/enid/Rundfunk/Senderdaten_5eg.html Have fun, the latitude, longitude is in it too ;-) I know the guy from http://emwg.info has a lot of AM locations, if he's prepared to work out a list.. Marc -- Shortwave transmissions in English, Francais, Deutsch, Suid-Afrikaans, Urdu, Cantonese, Greek, Spanish, Portuguese, ... http://users.fulladsl.be/spb13810/radio/swlist/ Stations list: http://users.fulladsl.be/spb13810/radio/txlist/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thoughts on an enhanced GPX api
On 28/07/09 11:33, Ævar Arnfjörð Bjarmason wrote: On Tue, Jul 28, 2009 at 9:04 AM, René Affourtitraffour...@gmail.com wrote: * All the data is losslessly inserted into the database This means that we can get waypoint/segment/time/ele/whatever data out again. It would probably be simplest to do this by having additional tables equivalent to the node/way tables where a GPX trkseg would be a way, waypoints nodes and so on. Track segment information is already preserved, as is elevation data even though we never use it (one day I'll get around to removing it...). * The data is versioned, and anyone can edit it I have a lot of GPX tracks that could be improved, e.g. by deleting point clouds. I'd like to edit them using normal OSM tools, have those edits versioned (so they can be rolled back), and have other users do those fixes for me. Just like with the OSM data I upload. GPS data is one of our fundamental pieces of evidence that we've surveyed things - is that really compatible with allowing people to edit it? Does editing the GPS data really make any sense at all? Maybe deletion of points makes sense, but I can't see that changing a point in any way should ever be allowed. * Users can download GPX traces: ** As a point cloud within a bbox Like now. ** As all tracks within bbox So that tracks can be distinguished (and hidden) and their metadata read edited. ** Using other methods E.g. all tracks by user Bearing in mind of course the privacy issues, at least with regard to legacy traces, including the question of privacy dilution if you make additional information available about the legacy public traces. Then, instead of deleting traces they (or their segments/points) could simply be tagged indicating their subjective quality using a free-form tagging system. You could then just set your editor to ignore those traces. Free-form tags could obviously be used for other purposes, e.g. marking the trace as surveyed with a given GPS model. Traces already have free form tags which can be edited, although currently only by the person that uploaded them. Implementing this would require new tables in the database, optional changes to all editors (since they could keep using /trackpoints), and new database tables to track GPX data and its history. Does it really need any new tables? I can't see why, unless you really want to pull track segments out into a separate table? What would be in there though other that the track ID and track segment ID - does a GPX file contain any information other than that about a segment? Waypoints is the other things I guess. I have considered adding them in the past but never quite got around to it. There was a historic argument against adding them but I think that can largely be ignored to be honest. How does this sound? I'm pretty happy with the 0.6 API except for the GPS bits. I'd like to make GPX a first-class object in OSM and would be willing to hack the rails port to make that happen (when I have time). Is anyone else interested in being able to do what I've described above? The API code is the easy bit - the performance and disk space issues will be the hard problems to solve. If we dropped the (unused and largely useless) elevation field from the points table and added a deleted flag that would keep the disk usage basically stable. The start point in the trace table, which isn't very useful, could be replaced by a bounding box to allow bbox queries - that's something that I have been thinking about doing for a while. Performance issues will mainly come into play if you want to do anything that requires cross-checking the point cloud against the trace list to determine what user owns it and/or whether it is public or not. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old GPS data
Also, and I've already posted here about that a while ago, it would really help if hdop, and eventually vdop, wasn't lost in the anonymization process. This is an important data when tracing, but unless you know who published the track and you can download the source, you don't have access to that information which is really a pity. And even if it implies a downtime while the database schema is upgraded, it would really be worth it. Yann Le 28 juil. 09 à 10:28, John Smith a écrit : --- On Tue, 28/7/09, Maarten Deen md...@xs4all.nl wrote: That is not indicative. A road could remain unchanged for the last 100 years or could have been demolished last year. What would be the expiration time of a track? And would you be prepared to lose correct GPS data to do this? Also as Liz put, some areas have very few traces so removing based on age is generally a bad idea, where as software specifying fewer tracks to show only the most recent might be the best way to handle it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
Roy Wallace waldo000...@gmail.com writes: On Tue, Jul 28, 2009 at 10:10 AM, Stephen Hopeslh...@gmail.com wrote: No, you're wrong here. Maxheight is an element of the way that goes under the bridge. It is caused by the bridge, but it is not part of the bridge. You're saying that the clearance under a bridge is not an attribute of the bridge? I'm not at all convinced of that. But it is subjective, so we may have to agree to disagree. The clearance under the bridge is, from the point of view of navigating, a property of the road under the bridge. You don't care when driving on the bridge - you can when going under it. That's where the max clearance signs are. I have never seen a sign on a bridge showing the clearance under it. (The point that a bridge could have height obstructions on it is also valid.) In fact the clearance is a joint property of the location of the underside of the bridge and the top of the road. Lowering the road a meter improves clearance, so saying this is just about the bridge makes no sense. pgpHxew0sECwQ.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Broken formatting of Wiki pages
Many of the UK wiki pages with 'place' and 'slippery map' templates are badly formatted, but not all. This one is badly formatted:- http://wiki.openstreetmap.org/wiki/East_Sussex and this one as well:- http://wiki.openstreetmap.org/wiki/County_Durham But this one is fine:- http://wiki.openstreetmap.org/wiki/Cambridgeshire Any ideas? Peter Miller ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Thoughts on an enhanced GPX api
On 28 Jul 2009, at 12:15, Tom Hughes wrote: The start point in the trace table, which isn't very useful, could be replaced by a bounding box to allow bbox queries - that's something that I have been thinking about doing for a while. I thought Potlatch used it for the edit links. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Important radio frequencies was: [tagging] Feature Proposal - RFC - information
Hello, I put a list for the fm online at http://users.fulladsl.be/~spb13810/research/ukwlist.gz format: name ; freq; lat; long Can you upload that to osm @ once ?? ;-) I use the tools on linux like: cut -c 5-35 UKW.TXT ukwloc cut -c 62-69 UKW.TXT ukwlat cut -c 70-76 UKW.TXT ukwlon cut -c 35-43 UKW.TXT ukwfreq paste -d ; ukwloc ukwfreq ukwlat ukwlon ukwlist Somebody will do the exercise for dvbt dabt, analogtv?? http://www.bundesnetzagentur.de/enid/Rundfunk/Senderdaten_5eg.html Marc -- Shortwave transmissions in English, Francais, Deutsch, Suid-Afrikaans, Urdu, Cantonese, Greek, Spanish, Portuguese, ... http://users.fulladsl.be/spb13810/radio/swlist/ Stations list: http://users.fulladsl.be/spb13810/radio/txlist/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Thoughts on an enhanced GPX api
On Tue, Jul 28, 2009 at 12:33 PM, Ævar Arnfjörð Bjarmasonava...@gmail.com wrote: On Tue, Jul 28, 2009 at 9:04 AM, René Affourtitraffour...@gmail.com wrote: So when a junction is reconstructed a local user can place a bounding box over that junction and all GPS points in that box are marked as outdated (or deleted, or whatever). Maybe some extra safety needs to be made by only allowing users active in the specific area to do this, or only users who upload traces. The problem with this is that it's a broken solution to an already limited system. We shouldn't have to /remove/ GPS tracks depending on age, but rather have the ability to mark segments or points of them as trusted (amongst other things). Maybe I wasn't very clear, I'm not talking about removing whole traces, but about marking points inside an area as invalid. e.g. Just south-west of Breda in the Netherlands the highway A16 has been moved a few hundred meters to the west over a distance of a few kilometers. Whatever traces that were made for that highway are still valid, except for these few kilometers and the connecting junctions. We want to keep the traces of the highway, and only 'remove'* the part that has been moved. (*) replace with delete/ mark invalid/ mark untrusted as you like. ... One problem with this is - as has been observed - that the data gets less useful for everyone as more traces are uploaded. We can devise hacky solutions to this such as not serving old traces via the API. But that's just a lame workaround which'll remove a lot of valid tracesi E.g. I've surveyed footways that have been there for centuries, and probably aren't going anywhere soon. What if the GPX API worked like this instead: ... * The data is versioned, and anyone can edit it I have a lot of GPX tracks that could be improved, e.g. by deleting point clouds. I'd like to edit them using normal OSM tools, have those edits versioned (so they can be rolled back), and have other users do those fixes for me. Just like with the OSM data I upload. In my opinion traces should be cleaned up before being uploaded, however I confess that I often don't do that :-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Thoughts on an enhanced GPX api
On 28/07/09 12:36, Shaun McDonald wrote: On 28 Jul 2009, at 12:15, Tom Hughes wrote: The start point in the trace table, which isn't very useful, could be replaced by a bounding box to allow bbox queries - that's something that I have been thinking about doing for a while. I thought Potlatch used it for the edit links. Yes, and it can perfectly easily use a bbox instead - arguably it's better in fact as the whole trace will appear (depending on area covered by the trace anyway). Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Broken formatting of Wiki pages
Peter Miller wrote: Many of the UK wiki pages with 'place' and 'slippery map' templates are badly formatted, but not all. This one is badly formatted:- http://wiki.openstreetmap.org/wiki/East_Sussex and this one as well:- http://wiki.openstreetmap.org/wiki/County_Durham But this one is fine:- http://wiki.openstreetmap.org/wiki/Cambridgeshire I changed the Geohack for OSM part on Template:place a bit. It looks better on the template page, but it appears the template is cached so it might take a little time before the pages look better. It should say More maps on Geohack for OSM in the corrected version. I suspect the original version had problems with page names that have spaces in them. For a quick fix I wasn't able to fix it so that it looked how user Kolossos made it originaly. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Broken formatting of Wiki pages
Maarten Deen wrote:
Peter Miller wrote:
Many of the UK wiki pages with 'place' and 'slippery map' templates
are badly formatted, but not all.
This one is badly formatted:-
http://wiki.openstreetmap.org/wiki/East_Sussex
and this one as well:-
http://wiki.openstreetmap.org/wiki/County_Durham
But this one is fine:-
http://wiki.openstreetmap.org/wiki/Cambridgeshire
I changed the Geohack for OSM part on Template:place a bit. It looks better
on the template page, but it appears the template is cached so it might take a
little time before the pages look better.
It should say More maps on Geohack for OSM in the corrected version.
I suspect the original version had problems with page names that have spaces
in them. For a quick fix I wasn't able to fix it so that it looked how user
Kolossos made it originaly.
Well, first fix did not do the trick (same space problem), but I saw the
solution in the same template: use {{urlencode:{{{name} if the name is to
be used in a URL. It will substitute '+' for space so the wiki does not get
confused.
Pages are still cached from where I see them (could be local cache), but see
http://wiki.openstreetmap.org/wiki/Tyne_and_Wear for proof.
And reverted my layout change to Kolossos' original version.
Regards,
Maarten
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Thoughts on an enhanced GPX api
On Tue, Jul 28, 2009 at 11:43 AM, René Affourtitraffour...@gmail.com wrote: On Tue, Jul 28, 2009 at 12:33 PM, Ævar Arnfjörð Bjarmasonava...@gmail.com wrote: I have a lot of GPX tracks that could be improved, e.g. by deleting point clouds. I'd like to edit them using normal OSM tools, have those edits versioned (so they can be rolled back), and have other users do those fixes for me. Just like with the OSM data I upload. In my opinion traces should be cleaned up before being uploaded, however I confess that I often don't do that :-) I currently have 61 MB of uploaded traces and 22 MB of un-uploaded ones. Some of those 61 MB have point clouds other unoptimal features. If I was really particular about what I'd upload that ratio would be closer to 22 MB uploaded 61 un-uploaded because I simply can't be bothered to do all that post-processing. Which is why I'd like to have infrastructure for doing that collaboratively so that I can offload the task to someone who's more keen to do it :) Currently when I'm editing data based on my traces I: * Upload my GPX trace to the site * Open JOSM with my *local* trace (since I can only get a point cloud from the site * Edit data based on it and cringe when I see things like point clouds, but I don't fix them because I can't be bothered to: * Open another program to edit my GPX tracks (I know about the EditGPX plugin b.t.w.) * Go to the OSM website - delete my track - re-upload it ( copy/paste all the track info because there's no replace track feature) In fact I often skip the first step and upload my tracks months later when I can get to it. That's because there's no direct benefit for my to upload my tracks to the site at all if I'm using on offline editor. The only advantage is to make it available for others for later reference to use osm.org as a free host for GPX tracks. I often see users who are using JOSM or another offline editor whose edits suggest that they're editing things based on GPX tracks even though they have no tracks uploaded, unsurprisingly as they probably can't see the how it benefits them. Instead what I'd like the workflow outlined above to look like is: * Upload my track to OSM site * Open JOSM - My uploaded tracks - Download Then I'd get a view with the OSM data in the foreground and my trace in the background. When I'd edit the OSM data I could easily pop into the GPX layer and do things like delete point clouds uplod them with a message deleted some useless point cloud points (which would show up in the revision log for the track). When editing maybe I'd see tracks from user xxyyzz notice that his track track partly goes across a way which I just surveyed s being demolished. I could then pop in and edit that as easily as a normal OSM way and add a tag indicating that that segment of xxyyzz's covers a feature that doesn't exist anymore. Although the rest of it is presumably OK. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Thoughts on an enhanced GPX api
Hi, Ævar Arnfjörð Bjarmason wrote: The problem with this is that it's a broken solution to an already limited system. We shouldn't have to /remove/ GPS tracks depending on age, but rather have the ability to mark segments or points of them as trusted (amongst other things). To be honest, I think that GPS traces are horribly overrated and will only further diminish in importance for OSM. I wouldn't spend a lot of time reinventing anything to do with GPS traces. I don't see a point in anyone editing a GPS point that someone else uploaded either. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline
- Original Message - From: Martijn van Oosterhout klep...@gmail.com To: Openstreetmap talk@openstreetmap.org Sent: Monday, July 27, 2009 4:46 PM Subject: Re: [OSM-talk] Coastline Forward to ML. On Mon, Jul 27, 2009 at 5:45 PM, Martijn van Oosterhoutklep...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:37 AM, David Groomrevi...@pacific-rim.net wrote: Yes. For mapnik, at high zoom levels the coast polygons used are generated from shapefiles created by the coastline error checker. The coastline error checker has been offline since sometime before mid June, so no updated shapefiles have been created. FWIW, I'm trying to get it working again (it was pointed out to me a few days ago that hypercube was back online) however I keep running into problems with corrupted planet dumps and daily diffs. I hope to have it working again soon. Thanks Martijn Its such a useful tool to have available David Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] is_in and similar tags
Is there a real need for is_in tags or have admin boundaries replaced the need? It seems there is a lot of redundancy going on for example node id = 17652780 aeroway = aerodrome closest_town = Newcastle, New South Wales ele = 9 iata = NTL icao = YWLM is_in = Australia, NSW, New South Wales name = Newcastle Airport name_1 = RAAF Base Williamtown name:en = Newcastle Airport operator = Royal Australian Air Force place = airport source = wikipedia type = Military wikipedia:en = RAAF_Base_Williamtown ___ 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] [talk-au] maxheight/height
2009/7/28 Liz ed...@billiau.net: To return to the bridge the following attributes of the bridge and the road underneath it all need to be considered a) Height of bridge height tag on bridge way b) Height above sea level of the bridge ele tag on bridge way c) Max height of the arch of the bridge above the roadway - a) d) Max height of a vehicle which can drive under the bridge, which if the bridge maxheight tag on the way under the bridge if you want to distinguish this from e), use a new tag (i.e. illegal but possible, e.g. clearance), but still on the way under the bridge. e) Max height of a vehicle which the engineer said was permitted to drive under the bridge maxheight tag on the way under the bridge If you want to explain explicitly in the data, why there is a height restriction on the way, put all involved ways in a bridge-relation. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thoughts on an enhanced GPX api
On Tue, Jul 28, 2009 at 11:15 AM, Tom Hughest...@compton.nu wrote: On 28/07/09 11:33, Ævar Arnfjörð Bjarmason wrote: On Tue, Jul 28, 2009 at 9:04 AM, René Affourtitraffour...@gmail.com wrote: * All the data is losslessly inserted into the database This means that we can get waypoint/segment/time/ele/whatever data out again. It would probably be simplest to do this by having additional tables equivalent to the node/way tables where a GPX trkseg would be a way, waypoints nodes and so on. Track segment information is already preserved, as is elevation data even though we never use it (one day I'll get around to removing it...). * The data is versioned, and anyone can edit it I have a lot of GPX tracks that could be improved, e.g. by deleting point clouds. I'd like to edit them using normal OSM tools, have those edits versioned (so they can be rolled back), and have other users do those fixes for me. Just like with the OSM data I upload. GPS data is one of our fundamental pieces of evidence that we've surveyed things - is that really compatible with allowing people to edit it? Does editing the GPS data really make any sense at all? Users are already editing GPX tracks before they upload them. Or deleting their tracks, editing them and then re-uploading them. Facilitating this editing within OSM would add more information to prove that we've surveyed things (since history would be kept), not less. Maybe deletion of points makes sense, but I can't see that changing a point in any way should ever be allowed. Not even to (as I suggested earlier in the thread) clarify the waypoint description? Anyway I'm not suggesting that GPX tracks should be edited willy-nilly. Just that allowing editing (which would be monitored!) would be a more cleaner and more general solution to the problem of aggregated GPS crud than ad-hoc solutions like expiring tracks after a given amount of time, or asking someone who's uploaded a lot of tag-cloud data in your area to delete his tracks (as was previously being suggested (on IRC I think) recently). * Users can download GPX traces: ** As a point cloud within a bbox Like now. ** As all tracks within bbox So that tracks can be distinguished (and hidden) and their metadata read edited. ** Using other methods E.g. all tracks by user Bearing in mind of course the privacy issues, at least with regard to legacy traces, including the question of privacy dilution if you make additional information available about the legacy public traces. It would make sense not to serve a more detailed format than a tag cloud for any traces not marked public, yes. (Aside from that users need to be made more aware of what marking things public/private or setting their location really means. I did my small bit towards that by adding a link to http://wiki.openstreetmap.org/wiki/Visibility_of_GPS_traces to the GPX upload form) Then, instead of deleting traces they (or their segments/points) could simply be tagged indicating their subjective quality using a free-form tagging system. You could then just set your editor to ignore those traces. Free-form tags could obviously be used for other purposes, e.g. marking the trace as surveyed with a given GPS model. Traces already have free form tags which can be edited, although currently only by the person that uploaded them. People can manually edit the GPX to add such metadata, but we don't make it easy. Which of course means that nobody does it. Implementing this would require new tables in the database, optional changes to all editors (since they could keep using /trackpoints), and new database tables to track GPX data and its history. Does it really need any new tables? I can't see why, unless you really want to pull track segments out into a separate table? What would be in there though other that the track ID and track segment ID - does a GPX file contain any information other than that about a segment? GPX supports arbitrary tags. If we were to import that losslessly serve it to users via an API we'd need more than just the current gps_points table (which only allows for a small subset of possible tags). To support arbitrary GPS tags we'd need gps_points and gps_point_tags (modeled after node_tags). So that e.g. gps_points.altitude would be removed and replaced by gps_point_tags.k = ele. Track segments could then be done by reusing the schema for current_ways/way_tags. And if editing was to be supported corresponding history tables would need to be created as well. Waypoints is the other things I guess. I have considered adding them in the past but never quite got around to it. There was a historic argument against adding them but I think that can largely be ignored to be honest. How does this sound? I'm pretty happy with the 0.6 API except for the GPS bits. I'd like to make GPX a first-class object in OSM and would be willing to hack the rails port to make that happen (when I
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] Broken formatting of Wiki pages
2009/7/28 Maarten Deen md...@xs4all.nl: I changed the Geohack for OSM part on Template:place a bit. It looks better on the template page, but it appears the template is cached so it might take a little time before the pages look better. It should say More maps on Geohack for OSM in the corrected version. The server uses job queues. The queue is used for purging template caches etc... I've forced a cache purge of those pages and they now seem in order. http://wiki.openstreetmap.org/wiki/Special:Statistics Queue is currently at 2487 which is fairly high, once load drops it'll start clearing the queue. / Grant ___ 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] Coastline
David Groom wrote: - Original Message - From: "Martijn van Oosterhout" klep...@gmail.com To: "Openstreetmap" talk@openstreetmap.org Sent: Monday, July 27, 2009 4:46 PM Subject: Re: [OSM-talk] Coastline Forward to ML. On Mon, Jul 27, 2009 at 5:45 PM, Martijn van Oosterhoutklep...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:37 AM, David Groomrevi...@pacific-rim.net wrote: Yes. For mapnik, at high zoom levels the coast polygons used are generated from shapefiles created by the coastline error checker. The coastline error checker has been offline since sometime before mid June, so no updated shapefiles have been created. FWIW, I'm trying to get it working again (it was pointed out to me a few days ago that hypercube was back online) however I keep running into problems with corrupted planet dumps and daily diffs. I hope to have it working again soon. Thanks Martijn Its such a useful tool to have available David +1 ___ 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
[OSM-talk] Poll: Syntax for restrictions with conditions
Hi, some of you might know my proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
or its predecessor, Conditions for access tags. The proposal presents
the idea of adding conditions to existing keys (such as maxspeed, access
...). A tag with conditions will only have an effect if all conditions
are valid. Something like this is necessary to describe many traffic
restrictions encountered in reality: restrictions only valid on wet
roads, at night, ...
The original proposal suggested using colons (:) to separate
conditions from the base key and each other. However, recently discussed
tagging concepts as well as the extensions introduced after the first
proposal have demonstrated some problems with that syntax. Most
importantly, colons
* are used by the {{tag|opening_hours}} syntax which imo would be a good
choice for timed restrictions
* are used as a namespacing solution and some recent ideas (such as
left/right ordering) might also use colons as a separator
* are used in situations where the order of key components matters. The
order of conditions, however, is semantically irrelevant.
Therefore, angle brackets ([ ]) have been suggested on talk-de as an
alternative to using colons.
Please state your opinion in the poll on the proposal's wiki page:
Which syntax do you prefer?
Tobias Knerr
___
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] [OSM-dev] planet hourly diff generation stopped 20090627 19:00
2009/7/27 Ciprian Talaba cipriantal...@gmail.com: And no daily diffs since July 25th. Fixed now. 20090727-20090728.osc.gz is current. / Grant ___ 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] Important radio frequencies was: [tagging] Feature Proposal - RFC - information
Hi, I started the process of getting tags for transmitters 'approved', these may be of use for you. http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower http://wiki.openstreetmap.org/wiki/Proposed_features/Communications_Transponder What you really need is some way to link a transmitter as a 'information' feature on a node/way, in the same way that the 'url' tag does Simon 2009/7/26 Elizabeth Dodd ed...@billiau.net: Can you suggest how I would map the sign Tourist Radio 88.1 which gives the frequency to tune your FM receiver for the information I am not sure that a sign would help us. But it could be interested if we have tag with important  radio frequencies of an area or especially of a tunnel. Radio with actual trafic information often found at the beginning of a tunnel radio:traffic = 92.4 MHz Toursit radio radio:tourist  = 88.1 MHz Ciao André ___ 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] [talk-au] maxheight/height
Roy Wallace waldo000...@gmail.com schrieb: On Tue, Jul 28, 2009 at 11:04 AM, Ross Scanloni...@4x4falcon.com wrote: Does this mean the bridge has a clearance of 2.8 or the road under the bridge has a clearance of 2.8. To me this would suggest the bridge has a limit of 2.8 ie vehicles travelling over the bridge can not be above 2.8 high. I'd suggest that if the bridge has a height limit, ie clearance, then the bridge is tagged with max_height. If the road under the bridge has a height limit, ie clearance, then the road is tagged. Sorry, maybe this is a language issue. In my mind, height limit of a way refers to maximum height *above* the way, whereas clearance of a way infers maximum height *under* the way. Maybe clearance isn't the best word for this - please suggest others. According to Wikipedia clearance [1] is the free space between a vehicle and the structure (i.e. bridge) it is passing through. The maximum height (and width) of the vehicle is -- at least for railways -- called loading gauge [2] while the dimensions of the structure are called structure gauge [3]. Thus, what we find on signs is the loading gauge. Christoph [1] http://en.wikipedia.org/wiki/Clearance [2] http://en.wikipedia.org/wiki/Loading_gauge [3] http://en.wikipedia.org/wiki/Structure_gauge ___ 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
