Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
Not that I would suggest that we emulate the Ordnance Survey (;) - but in England and Wales the OS map is currently the only readily accessible map that tells normal walkers, cyclists and riders where they may go. Bear in mind we have no 'jokamiehenoikeus'/'allmannsrät' in this country, i.e. in the countryside the public only has the right to walk/cycle/ride where this right exists - the default is NO rights (except on access land since the CROW Act) - the opposite of Germany, Scandinavia, etc. Signage does not reliably give this information either - for example, some landowners seem to have a magic potion that makes signs disappear at regular intervals! So wouldn't it be nice if this (publicly available and non-copyright, possible - but not always easy - to find without using an OS map) information were also available on OSM? It's one of the reasons I started working as an off-road mapper in the OSM community in the UK. Mike Harris -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: 13 August 2009 23:26 To: Roy Wallace Cc: osm Subject: Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway] 2009/8/14 Roy Wallace waldo000...@gmail.com: Absolutely true: explicit in the wiki ;-) We have a database, let's populate it. The wiki is to help instruct people how to best populate the database - it should not be a part of the database itself. but this is not real map-information but it is legal information you could also get from different sources. If a way is legally a cycleway, all the laws and implications in that county apply automatically. You just need the info: it is a cycleway (and not simply a way where you can cycle, but one designated as such). That's why I would _not_ put foot=no, motorcar=no, hgv=no, psv=no, goods=no, horse=no, motorcycle=no, moped=no, airplanes=no, llamas=no on every single cycleway. It is implied. I would put foot=yes if they are allowed. The proposed wiki-table would just be for the comfort of the mappers (summarize the legal situation and document it in a OSM-focused way), but it would not be required to read the map (if you know the local laws). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
'gewidmet' does best translate as 'dedicated' - but in English law that is something different to 'designated' (at least as 'designated' is defined on the wiki). In practice, 'dedicated' can mean the process by which something becomes 'designated' (in this context) OR it can mean a path that a landowner allows to be used by the public (i.e. a 'permissive path) because he has voluntarily 'dedicated' it in that way - as well as a public right of way. I would tend to steer clear of 'dedicated' in English because it is potentially ambiguous. I would tend to translate 'designated' as 'bestimmt' or 'bezeichnet' but am unsure which is better! (it doesn't imply anything about signage per se - although there are certain legal obligations on the authority to erect signs at certain types of points). .. And this is just the ambiguity arising between a single language pair! Mike Harris -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: 14 August 2009 02:51 To: Roy Wallace Cc: osm Subject: Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway] 2009/8/14 Roy Wallace waldo000...@gmail.com: On Fri, Aug 14, 2009 at 8:26 AM, Martin Koppenhoeferdieterdre...@gmail.com wrote: 2009/8/14 Roy Wallace waldo000...@gmail.com: but this is not real map-information but it is legal information you could also get from different sources. If a way is legally a cycleway, all the laws and implications in that county apply automatically. highway=cycleway (and footway) has inconsistent implications. This is the problem, and this occurs even within areas with the same law. I think this makes cycleway an inherently bad tag (as currently used). in Italy (and probably in Germany more or less as well) we use highway=cycleway if there is a cycleway-sign (blue with white bike). Other ways are not cycleways, but could get bicycle=yes. You suggest we use the wiki to supplement the database - that's fine, Yes. This is somehow already done by defining possible meanings of the tags. I wrote that legal implications within a certain country could be documented in the wiki, so it's not necessary to tag them all explicitly (like motorcar=no, foot=no on cycleways). This is actually already done, e.g. in the German wiki pages. It's theoretically no problem to tell in which country a way is, just by the map data, as long as we have precise borders (might require some preprocessing though). BUT within the database highway=cycleway must mean the same thing as highway=cycleway. That's called consistency. Putting extra stuff in the wiki *cannot* give the database consistency. the problem is, that real world is not consistent across borders. If you say: all ways that are marked as cycleways (sign or painted on the street) are to tag as cycleways, this will mean different implicit access-tags in different countries. I can't see a real problem here though. It would be nice to have for the main features a per-country-list the transcripts local legislation in OSM (define default-presets). Cases not according to those presets would be tagged explicitly. You make the point that we should be entering real map-information in the database. I agree, and interpret this as meaning the database should represent the situation on the ground (and not necessarily aim to capture also the situation in the law books - unless this can be done in a separate namespace, e.g. law:*=*, as others have suggested). well, I'm not a pure on the ground-guy, I think what ever information you figure out and could potentially be useful I encourage to put into the database. But tagging the default law-situation for every single way seems exaggerated to me - hence we use classification and xy=designated to describe with one or two tags a series of implications for ways. Maybe there is a slight language problem though: many of the tags are proposed by non-native speakers. I rember the discussion about path on the German ML and someone said gewidmet (I think in Engl. dedicated, it is in this context the process of legally assigning a road class to a way) translates to designated and maybe therefore it's like this now. If you look in a common Engl-German dictionary you'll find several not congruent translations: http://dict.leo.org/?lp=endefrom=fx3search=designated cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
You seem to be implying that increasing the amount of data in OSM is a bad thing??? Increasing the amount of _implicit_ data surely is. There are good reasons, why putting implicit data into databases is usually avoided. Of course, llama access restrictions probably aren't a top priority, but it IS a GOOD THING to have llama restrictions in the database. The core issue here (that I believe we agree on) is that if tags have inconsistent implications, they must be made explicit. But in most cases they are locally consistent, thus it makes sense to simply assume different defaults for different countries/jurisdictions. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
The core issue here (that I believe we agree on) is that if tags have inconsistent implications, they must be made explicit. Absolutely true: explicit in the wiki ;-) I don't think the wiki is a good place for that. Keep in mind that these defaults would be nice to have in a machine-readable format. They could be stored in the DB, too. Maybe this would be an extension for API 0.7: a way to express the defaults (and implications) for various tags depending on the country. Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On 13/08/2009 18:20, Norbert Hoffmann wrote: David Earl wrote: So I say: keep it simple, keep it compatible. Carry on with the simple, established tags we already have, but just clarify the default use classes which apply to each highway tag, PER COUNTRY, and tag exceptions to these according to evidence on the ground. Add specific legal designations only where expert knowledge is available and different from the default interpretation. I say: forget all defaults and store all those values in the database. Those only partly documented defaults are the cause of the discussed problems. The process of tagging may be as simple as it is now. Let the user choose which country he is in (or which country's rules are in his head while editing) and than the editor can add those defaults. What we win with this method is, that the apps working with the data need not know anything about country borders or specific legals and changing some default in the WIKI will no longer invalidate data. So what you're saying is that - each editor and data consumer has to have its own set of national rules and defaults rather than defining them centrally (so inevitably they'll end up different); - we have to massively increase the amount of data we store by saying for every road that it is open 24 hours a day (because some aren't) and has a 44 tonne weight limit (or whatever it is by default in your country) except for the few cases where it isn't; all cycleways don't permit llama pack animals (because some in Peru do) and all motorways explicitly do or don't permit horse drawn vehicles. - we can't type a simple tag any more, we have to go via a menu or a form because there are so many of them. Every highway would have to carry maybe thirty or forty tags giving use cases, and every time we realise we are missing a use case (say we discover motorways in Ecuador permit learner drivers to use them [please don't tell me this isn't the case - it's only an example]) we have to add tags to every other highway in the world to say that there learner drivers can't, otherwise we're assuming a default. - and that we have to update almost every way in the system already and change every bit of software we already have David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On 08/13/2009 01:24 PM, David Earl wrote: realise we are missing a use case (say we discover motorways in Ecuador permit learner drivers to use them [please don't tell me this isn't the case - it's only an example]) we have to add tags to every other highway you don't even have to go that far -- at least some, probably most or all, states in the US allow learner drivers to use the motorway/freeway/interstate. -Alex mauer Hawke signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On Thu, Aug 13, 2009 at 13:37, Alex Mauerha...@hawkesnest.net wrote: On 08/13/2009 01:24 PM, David Earl wrote: realise we are missing a use case (say we discover motorways in Ecuador permit learner drivers to use them [please don't tell me this isn't the case - it's only an example]) we have to add tags to every other highway you don't even have to go that far -- at least some, probably most or all, states in the US allow learner drivers to use the motorway/freeway/interstate. Very true about the States. My first time behind the wheel of a car on a public road was on the end of a motorway to nowhere, because that stretch of road was wide with large curve radii, had no cross traffic or oncoming traffic, and was relatively lightly traveled (it was brand new at the time and the last couple of miles were built through rural areas in anticipation of future demand for roads into the city.) -- David J. Lynch djly...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On Thu, Aug 13, 2009 at 8:24 PM, David Earlda...@frankieandshadow.com wrote: So what you're saying is that - each editor and data consumer has to have its own set of national rules and defaults rather than defining them centrally (so inevitably they'll end up different); - we have to massively increase the amount of data we store by saying for every road that it is open 24 hours a day (because some aren't) and has a 44 tonne weight limit (or whatever it is by default in your country) except for the few cases where it isn't; all cycleways don't permit llama pack animals (because some in Peru do) and all motorways explicitly do or don't permit horse drawn vehicles. - we can't type a simple tag any more, we have to go via a menu or a form because there are so many of them. Every highway would have to carry maybe thirty or forty tags giving use cases, and every time we realise we are missing a use case (say we discover motorways in Ecuador permit learner drivers to use them [please don't tell me this isn't the case - it's only an example]) we have to add tags to every other highway in the world to say that there learner drivers can't, otherwise we're assuming a default. - and that we have to update almost every way in the system already and change every bit of software we already have David all +1. And it's clear that if the wiki is used as reference for defaults, it will be watched by many people and risks of vandalism on this part is very small. And applications don't have necessarily to know in which country they are, defaults can be preprocessed for their needs (e.g. for routing). Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
David Earl wrote: So what you're saying is that - each editor and data consumer has to have its own set of national rules and defaults rather than defining them centrally (so inevitably they'll end up different); The editors must have some way to set defaults, the consumers will get a full dataset. So they must know the defaults plus the interpretation of the tagger(!) *now* but not later. - we have to massively increase the amount of data we store by saying for every road that it is open 24 hours a day (because some aren't) and has a 44 tonne weight limit (or whatever it is by default in your country) except for the few cases where it isn't; all cycleways don't permit llama pack animals (because some in Peru do) and all motorways explicitly do or don't permit horse drawn vehicles. The most common values (by highest count) can be left out from the *db* and only be stored once. So yes, there must db-wide-defaults. - we can't type a simple tag any more, we have to go via a menu or a form because there are so many of them. Every highway would have to carry maybe thirty or forty tags giving use cases, Shure you can tag cycleway and nothing else, but you'll have tell the editor once, what a cycleway means to you. and every time we realise we are missing a use case (say we discover motorways in Ecuador permit learner drivers to use them [please don't tell me this isn't the case - it's only an example]) we have to add tags to every other highway in the world to say that there learner drivers can't, otherwise we're assuming a default. If you'll need to update any record in the table for this is a question of design. - and that we have to update almost every way in the system already why? and change every bit of software we already have why? Norbert playing advocatus diaboli ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On Thu, Aug 13, 2009 at 11:45 PM, Roy Wallacewaldo000...@gmail.com wrote: You seem to be implying that increasing the amount of data in OSM is a bad thing??? If it is millions time the same thing, yes. Look another thread speaking about TIGER import clean-up. Of course, llama access restrictions probably aren't a top priority, but it IS a GOOD THING to have llama restrictions in the database. Yes, it is. In PERU. The core issue here (that I believe we agree on) is that if tags have inconsistent implications, they must be made explicit. Absolutely true: explicit in the wiki ;-) Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On Fri, Aug 14, 2009 at 8:03 AM, Pierenpier...@gmail.com wrote: Of course, llama access restrictions probably aren't a top priority, but it IS a GOOD THING to have llama restrictions in the database. Yes, it is. In PERU. I'd be quite happy to know whether I can ride my llama down my street in Australia. Why are you afraid of more data? The core issue here (that I believe we agree on) is that if tags have inconsistent implications, they must be made explicit. Absolutely true: explicit in the wiki ;-) We have a database, let's populate it. The wiki is to help instruct people how to best populate the database - it should not be a part of the database itself. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
2009/8/14 Roy Wallace waldo000...@gmail.com: Absolutely true: explicit in the wiki ;-) We have a database, let's populate it. The wiki is to help instruct people how to best populate the database - it should not be a part of the database itself. but this is not real map-information but it is legal information you could also get from different sources. If a way is legally a cycleway, all the laws and implications in that county apply automatically. You just need the info: it is a cycleway (and not simply a way where you can cycle, but one designated as such). That's why I would _not_ put foot=no, motorcar=no, hgv=no, psv=no, goods=no, horse=no, motorcycle=no, moped=no, airplanes=no, llamas=no on every single cycleway. It is implied. I would put foot=yes if they are allowed. The proposed wiki-table would just be for the comfort of the mappers (summarize the legal situation and document it in a OSM-focused way), but it would not be required to read the map (if you know the local laws). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On Fri, Aug 14, 2009 at 8:26 AM, Martin Koppenhoeferdieterdre...@gmail.com wrote: 2009/8/14 Roy Wallace waldo000...@gmail.com: but this is not real map-information but it is legal information you could also get from different sources. If a way is legally a cycleway, all the laws and implications in that county apply automatically. highway=cycleway (and footway) has inconsistent implications. This is the problem, and this occurs even within areas with the same law. I think this makes cycleway an inherently bad tag (as currently used). You suggest we use the wiki to supplement the database - that's fine, BUT within the database highway=cycleway must mean the same thing as highway=cycleway. That's called consistency. Putting extra stuff in the wiki *cannot* give the database consistency. So I should probably now propose a solution rather than just criticise others': You make the point that we should be entering real map-information in the database. I agree, and interpret this as meaning the database should represent the situation on the ground (and not necessarily aim to capture also the situation in the law books - unless this can be done in a separate namespace, e.g. law:*=*, as others have suggested). So, how about the following consistent scheme?: 1) A yes/no tag that indicates signage 2) A yes/no tag that indicates legality (independent of signage) - feel free to not put this in the database if you don't want 3) A yes/no tag that indicates a subjective recommendation/suitability judgement (should be discouraged in favour of width=* and surface=*, but will often still be useful) As others have requested, this would separate the legal information from what's on the ground. These tags could be called: 1) *=designated/designated_no (would require slight change to wiki definition and introduction of designated_no) 2) *=yes/no (seems to reflect current wiki definition) 3) *=suitable/unsuitable (don't think there's currently a tag for this, probably because it's not verifiable - but people probably often mistakenly use *=yes/no for this) These could be used as values, with the mode of transport as the key, i.e. *=designated/designated_no, *=yes/no, *=suitable/unsuitable (this should look familiar). But then you can only use *one of these values per mode of transport*, which is problematic. To avoid this, I would prefer a nicer structure (suggested recently in relation to the school_zone proposal), with keys as keys and values as values, as in: 1) designated:vehicle=*;yes/no 2) access:vehicle=*;yes/no 3) suitable:vehicle=*;yes/no The general format, which could be extended to all kinds of access restrictions, is: X:K = L;V, where X = the standard tag (maxspeed, or access, or bicycle, etc.) K = the kind of condition L = the value of the condition (in an appropriate format according to K) V = the value for X (e.g. yes/no, speed in kmph, etc.) I realise this would involve a big change in syntax - but as soon as people start asking for the ability to tag more than 1 aspect of a way (say, legal vs suitability vs signage) in relation to, say, bicycles, you need to put bicycle in the value field. Let me know if anyone's interested in a proposal in this format. Conversely, let me know if I'm wasting my time. Anyway, if you want to know if you can ride your llama down the street, you need to refer to *:vehicle=llama;* or infer it from the values of the other tags. IMHO, this is the best we can do, and is better than requiring software to look up the default value for llama=* on a cycleway in Peru from the wiki. Using the above scheme in combination with highway=path, cycleway/footway would become unnecessary, but could still co-exist with their current definitions (which is something along the lines of who knows?). Apologies for bashing everyone over the head with another scheme, but I couldn't help myself. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On Fri, Aug 14, 2009 at 9:46 AM, Roy Wallacewaldo000...@gmail.com wrote: The general format, which could be extended to all kinds of access restrictions, is: X:K = L;V, where X = the standard tag (maxspeed, or access, or bicycle, etc.) K = the kind of condition L = the value of the condition (in an appropriate format according to K) V = the value for X (e.g. yes/no, speed in kmph, etc.) Correction, X = the standard tag (maxspeed, or access, etc.) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
2009/8/14 Roy Wallace waldo000...@gmail.com: On Fri, Aug 14, 2009 at 8:26 AM, Martin Koppenhoeferdieterdre...@gmail.com wrote: 2009/8/14 Roy Wallace waldo000...@gmail.com: but this is not real map-information but it is legal information you could also get from different sources. If a way is legally a cycleway, all the laws and implications in that county apply automatically. highway=cycleway (and footway) has inconsistent implications. This is the problem, and this occurs even within areas with the same law. I think this makes cycleway an inherently bad tag (as currently used). in Italy (and probably in Germany more or less as well) we use highway=cycleway if there is a cycleway-sign (blue with white bike). Other ways are not cycleways, but could get bicycle=yes. You suggest we use the wiki to supplement the database - that's fine, Yes. This is somehow already done by defining possible meanings of the tags. I wrote that legal implications within a certain country could be documented in the wiki, so it's not necessary to tag them all explicitly (like motorcar=no, foot=no on cycleways). This is actually already done, e.g. in the German wiki pages. It's theoretically no problem to tell in which country a way is, just by the map data, as long as we have precise borders (might require some preprocessing though). BUT within the database highway=cycleway must mean the same thing as highway=cycleway. That's called consistency. Putting extra stuff in the wiki *cannot* give the database consistency. the problem is, that real world is not consistent across borders. If you say: all ways that are marked as cycleways (sign or painted on the street) are to tag as cycleways, this will mean different implicit access-tags in different countries. I can't see a real problem here though. It would be nice to have for the main features a per-country-list the transcripts local legislation in OSM (define default-presets). Cases not according to those presets would be tagged explicitly. You make the point that we should be entering real map-information in the database. I agree, and interpret this as meaning the database should represent the situation on the ground (and not necessarily aim to capture also the situation in the law books - unless this can be done in a separate namespace, e.g. law:*=*, as others have suggested). well, I'm not a pure on the ground-guy, I think what ever information you figure out and could potentially be useful I encourage to put into the database. But tagging the default law-situation for every single way seems exaggerated to me - hence we use classification and xy=designated to describe with one or two tags a series of implications for ways. Maybe there is a slight language problem though: many of the tags are proposed by non-native speakers. I rember the discussion about path on the German ML and someone said gewidmet (I think in Engl. dedicated, it is in this context the process of legally assigning a road class to a way) translates to designated and maybe therefore it's like this now. If you look in a common Engl-German dictionary you'll find several not congruent translations: http://dict.leo.org/?lp=endefrom=fx3search=designated cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
