Re: [Tagging] paved=yes/no
On 17 July 2010 14:55, Steve Bennett stevag...@gmail.com wrote: Do data modelling perspectives normally deal with folksonomies though? By its very nature, the data entered by OSM editors is far more susceptible to inconsistency than, say, a corporate database. There is plenty of commercial and government databases that show lots of inconsistencies, entirely depends on the amount of resources to make it better. Also, the errors you're talking about (ie, paved=yes, surface=grass) are perfectly resolvable: define a priority. If surface=grass doesn't agree with paved=yes, then ignore it. (Or vice versa). In which case is there any point having it in the first place, how do you know which is correct and which isn't? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] paved=yes/no
At 2010-07-16 21:55, Steve Bennett wrote: On Fri, Jul 16, 2010 at 2:57 PM, Richard Welty rwe...@averillpark.net wrote: from a data modeling perspective, though, it's redundant and thus creates the opportunity for inconsistency and unresolvable error. Do data modelling perspectives normally deal with folksonomies though? By its very nature, the data entered by OSM editors is far more susceptible to inconsistency than, say, a corporate database. I really worry about the long-term effects of this, though. Eventually, if renderers have to deal with all those duplicate (and not-quite-duplicate) cases, they will slow to a crawl. Shouldn't we at least try to stem this where we can? The current planet tagwatch has 19243 different keys, and shop, leisure, and amenity have over 1000 values each. Many of these are mis-spellings, capitalization errors, import-source-specific tags, etc., rantbut it also seems like a lot of people aren't bothering to search for existing tags for what they want to map - they just make something up, often without even consulting a dictionary - as if nobody else in the world had ever tagged a fast-food joint or shoe store. /rant This is not a great comparison, but it's all I have access to at the moment. If I use the US tagwatch from 20091206, and look only at keys starting with lower-case letters and that do not contain colons, there are just 1650 such keys. By comparison, the 20100707 planet tagwatch has 7223 such keys. If someone has the last US tagwatch, we could do a better comparison, but there does seem to be a growing problem here. -- Alan Mintz alan_mintz+...@earthlink.net ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] paved=yes/no
On 7/17/10 8:20 AM, Steve Bennett wrote: This isn't a problem I have any idea how to resolve just now. My comments above were quite simple: having inconsistent paved=yes/no, and surface=xxx is not a problem, because the central authority (whatever it is) can simply define one as taking precedence over the other in the event of any inconsistency. ummm, does this type of semantic (with two inconsistent tags, one has priority) appear anywhere else in OSM? if not, this is a pretty significant change, one that really requires a proper proposal and vote. if we just discuss this and don't do anything, then the addition of unpaved will simply stand as it is right now, without the introduction of these semantics. i might add that if we're looking at the introduction of new semantics in order to make adding unpaved=yes/no ok, it's going to take a great deal to convince me. richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] paved=yes/no
On 2010-07-16 at 06:50, Steve Bennett wrote: On Fri, Jul 16, 2010 at 8:43 AM, John Smith deltafoxtrot...@gmail.com wrote: That was what I was trying to figure out, is there a good reason for such a tag, or is it going to just confuse people. IMHO yes it's useful, because the paved/unpaved distinction is by far the most important one for roads. The problem is that surface=* is an unbounded list, so renderers potentially have to support surface=dirt, gravel, cobblestone, mud, cracked_concrete, rough, and whatever else peoples' fertile imaginations come up with. So what if my application distinguishes between continuous paving (asphalt, concrete, ...), tiled paving (paving_stones, cobblestone, grass_paver, ...), and unpaved? Should I invent another tag like paving=continuous/tiled/none? While the list of surface values is *potentially* unbounded, it is finite at any given time. For practical purposes, just teach that list of surface values on the wiki to your renderer, do a quick tagwatch check to find out whether there is some other really common value and ignore the rest. Most mappers tend to stick to well-known values anyway. (That's even more true for the increasing number of editor preset users.) If you write an application or rendering style, don't worry too much about mappers sabotaging your style by inventing a new surface value for every road. You see, mappers actually want their data to be useful. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Highway services operator
On the wiki [0] I found the operator tag to describe the operator of a certain service area. Now what is this tag supposed to describe? The fuel station operator? The restaurant/bar/fast food operator? Other? May other amenities/services be inserted? E.g. - semicolon-separated services=* - atm=yes/no Thw wiki entry is absolutely lean about these aspects Stefano http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Highway services operator
On Sat, 17 Jul 2010 18:47:04 +0200, Stefano Pallicca wrote: On the wiki [0] I found the operator tag to describe the operator of a certain service area. Now what is this tag supposed to describe? The fuel station operator? The restaurant/bar/fast food operator? Other? May other amenities/services be inserted? E.g. - semicolon-separated services=* - atm=yes/no One that comes to mind is the potential tags for a Taco Bell owned by Pacific Bells, Inc., common in Oregon: name=Taco Bell amenity=fast_food cuisine=mexican operator=Pacific Bells, Incorporated Or for a corporate-owned Sonic, common in Oklahoma: name=Sonic Drive-In amenity=fast_food cuisine=american operator=Sonic Restaurants, Incorporated ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC on two proposals: Motorway indication; Expressway indication
On Fri, 16 Jul 2010 16:48:49 -0400, Nathan Edgars II wrote: I think the two of you are using different definitions of access restrictions. The ones that are implied by motorway relate to whether certain vehicles (such as bicycles or shoes) can access the road, while a surface expressway (and a motorway) restricts adjacent property owners from building driveways to access the road. Motorway doesn't (or shouldn't) imply any access restrictions, just that it doesn't have at-grade intersections (save for emergency vehicle, or rarely, extremely rural range access). 28 states allow all modes on all roads, for example, so it's not reasonable to make any access assumptions based on the highway=motorway tag. Oregon, Washington and British Columbia are good examples of where this applies. A few states, usually those with turnpikes, allow bicycles on expressways (trunks: motorways with at-grade intersections) and freeways (toll-free motorways), but not on turnpikes (toll motorways). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Highway services operator
On 18 July 2010 03:49, Paul Johnson ba...@ursamundi.org wrote: One that comes to mind is the potential tags for a Taco Bell owned by Pacific Bells, Inc., common in Oregon: name=Taco Bell amenity=fast_food cuisine=mexican operator=Pacific Bells, Incorporated Or for a corporate-owned Sonic, common in Oklahoma: name=Sonic Drive-In amenity=fast_food cuisine=american operator=Sonic Restaurants, Incorporated This came up the other day in an almost identical thread, the name out the front isn't the same as the restaurant name, and you should tag that as the brand=* http://lists.openstreetmap.org/pipermail/talk/2010-July/051698.html ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging