[Tagging] Patisserie?
I'm using Mapzen POI collector and current version of Mapzen POI collector uses abandoned feature patisserie: http://wiki.openstreetmap.org/wiki/Abandoned_features AFAIK it should be tagged like this: amenity=cafe cuisine=cake Right? -- pratite me na twitteru - www.twitter.com/valentt blog: http://kernelreloaded.blog385.com linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Patisserie?
2010/10/28 Valent Turkovic : > I'm using Mapzen POI collector and current version of Mapzen POI > collector uses abandoned feature patisserie: > http://wiki.openstreetmap.org/wiki/Abandoned_features > > AFAIK it should be tagged like this: > amenity=cafe > cuisine=cake I'd say this depends on the place, by reading the title I thought you were writing about a "shop". cuisine=cake doesn't sound right to me, although this represents 0.1% of all cuisine tags. There is 61 items tagged as shop=patisserie which isn't overwhelming either. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Patisserie?
On Thu, Oct 28, 2010 at 9:39 AM, Valent Turkovic wrote: > I'm using Mapzen POI collector and current version of Mapzen POI > collector uses abandoned feature patisserie: > http://wiki.openstreetmap.org/wiki/Abandoned_features > > AFAIK it should be tagged like this: > amenity=cafe > cuisine=cake > > Right? > > Not in France. It's really a shop like a bakery (and is often combined but not always). You may or may not be able to eat on place (tea room). It's surely not a 'cafe' although some 'cafe' provide cakes but they come from the nearby patisserie. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Patisserie?
On Thu, Oct 28, 2010 at 10:56 AM, M∡rtin Koppenhoefer wrote: > 2010/10/28 Valent Turkovic : >> I'm using Mapzen POI collector and current version of Mapzen POI >> collector uses abandoned feature patisserie: >> http://wiki.openstreetmap.org/wiki/Abandoned_features >> >> AFAIK it should be tagged like this: >> amenity=cafe >> cuisine=cake > > > I'd say this depends on the place, by reading the title I thought you > were writing about a "shop". cuisine=cake doesn't sound right to me, > although this represents 0.1% of all cuisine tags. There is 61 items > tagged as shop=patisserie which isn't overwhelming either. > > cheers, > Martin http://wiki.openstreetmap.org/wiki/Key:cuisine I'm reading this from wiki, so maybe I misunderstood it? Any clarification would be appreciated. How to tag patisserie? It is a shop that main business is selling cakes, but also has ice-cream and cafe. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Super-relations or not (was: Relation member_roles from Osmosis import)
(sorry for the crossposting, but this really applies globally, as well as for recent discussions on the talk-us list) Ian Dees writes: > On Thu, Oct 28, 2010 at 9:14 AM, Peter Budny wrote: > > Jochen Topf writes: > > > On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: > > > > Thats a left-over from the time when relation members were not > > ordered. > > Someone in another thread just told me relation members /aren't/ > ordered, and that the ordering that, say, JOSM displays is just as a > tool to aid the user... not for any semantic purpose. Which is it? > > > http://wiki.openstreetmap.org/wiki/Elements#Relation says "The ordering of > elements within a relation is persistent. The members are returned in the > order specified at upload. Duplicate elements will retain their specified > order." Aha. Now that's interesting. To me, this says we really ought to be using super-relations for route relations, rather than a single relation with roles tagged, for 2 reasons: 1) The common way, up to now, for storing routes that alternate between single- and dual-carriageway has been to leave the single-carriageway parts without a role, or with the role "north/south". This makes the order of the members of the relation meaningless, since you can't traverse the ways end-to-end in the specified order. This could be solved by adding the single-carriageway sections twice (once with "north" and once with "south"), but at that point, why not take the extra 5 seconds and do super-relations? 2) If the direction of a road (e.g. north/south) is indicated by roles, how do you refer to it elsewhere? For example, if you have a destination sign that says it goes to I-75 Northbound, and all of I-75 is in one relation with roles for "north" and "south", how do you refer to just one direction of the road? You can't refer to the whole relation (because that doesn't reflect what the sign says), and there's no clear way to refer to a role of a relation. With super-relations, this isn't a problem... there would be a subrelation that unambiguously refers to just the northbound or southbound part of the road. I really think that super-relations for routes are the way to go... all the methods are really equivalent, but super-relations are easier to deal with programmatically, preserve a little more information, and are not really any more difficult for users/mappers. If anyone has a compelling argument against super-relations, or for single relations, I'd like to hear it. Supporting both seems really pointless, and I think it's about time we picked one or the other so we can develop proper support for route relations and tools to support them moving forward. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Super-relations or not (was: Relation member_roles from Osmosis import)
On 28 Oct 2010, at 7:51 , Peter Budny wrote: > > To me, this says we really ought to be using super-relations for route > relations, rather than a single relation with roles tagged, for 2 > reasons: > yes, absolutely, the relation with role is very limited, one more reason is the checking tools for completeness. there is a relation checker and it will find one single ordered and connected set of ways. easy to verify broken routing. if a relation passes it also means all ways are connected, no duplicates in the route relation … it's almost a routing graph > > ___ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] levees
Is there a standard way to tag a levee? It seems that highway=track embankment=yes would work for the vast majority of cases, but there may be some that service vehicles can't drive on. Also, levees (at least in swampland) often have an associated adjacent canal without its own name. This is sometimes called the '[levee name] borrow canal' (http://www.google.com/search?q=%22L-30+borrow+canal%22), since the fill for the levee came from what's now a canal, or simply the '[levee name] canal' (http://www.google.com/search?q=%22L-30+canal%22). Should this be separately tagged with such a name, or is it assumed that a canal next to a levee shares a name (like a sidewalk next to a road)? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-us] stop signs
On 10/27/2010 11:47 AM, Peter Wendorff wrote: > Another point is: if forward/backward is used, a mapper can see with > common knowledge, that tagging a stop sign at the intersection node is > no good idea. Compass could in theory be tagged at the intersecting > node, too. It's possible and with resolution of some meters in mind it's > "exactly enough" for some people. Drawback would obviously be to tag > more than one heading direction at once, but I'm sure there will be > people tagging compass=X,Y as multivalue property. Forward and back don't really work if the direction of the way gets reversed for some reason. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-us] stop signs
On 10/27/2010 08:26 AM, M∡rtin Koppenhoefer wrote: > 2010/10/27 : >> I have never seen a stop sign at a railroad crossing. Buses are required by >> law to stop before a railroad crossing, and open the bus door so that the >> driver can better hear if a train is approaching. Some other commercial >> vehicles routinely stop as well, but private vehicles aren't required to >> stop. >> >> If there is a jurisdiction that places stop signs at each railroad crossing, >> I would be interested in learning where it is. > > > really I don't see the point of this discussion anymore: I already > question the benefit of tagged stop signs in general, as a stop sign > itself requires very few seconds of travel time, while a unregulated > crossing with a lot of traffic from the right might require a lot > more, it all depends merely on traffic density (which itself is quite > dependent on the time). But why should we conduct research on > "jurisdiction that places stop signs at each railroad crossing" or > stuff like this? Is our way of mapping stop signs (or better the > "requirement to stop") depending on this? Where I'm at, most of the streets AND avenues are numbered away from downtown Tulsa, and we're far enough that any three-digit street looks about the same as any three-digit avenue that nobody bothers to remember them unless they happen to have an address on it. Instead, you're likely to get directions like "Turn right after the truck stop and turn left at the second stop sign" from someone. Being one of the few landmarks actually visible from the street far enough in advance to actually navigate by in the woods, yield and stop signs often end up as navigational reference by themselves. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Difference between footway and pedestrian
On 10/26/2010 04:19 PM, Noel David Torres Taño wrote: > Hello all: > > There are two values highway=footway and highway=pedestrian and I do not know > which are the differences between them. The wiki does not contain a decisive > difference mark. Look in Portland, Oregon around the Rose Garden Arena for some good examples of both. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-us] stop signs
On 10/27/2010 10:24 AM, Anthony wrote: > On Wed, Oct 27, 2010 at 10:27 AM, M∡rtin Koppenhoefer > wrote: >> 2010/10/27 Anthony : >> >>> One proposal for mapping stop signs is that the stop sign always faces >>> opposite the nearest intersection. >> >> so let's discuss about this. I don't think it is a good idea to have >> implicit facing, I would prefer to - at least in exceptional cases - >> be able to define manually which is the facing of the sign, or better: >> on which way at which point (intersection) there is a stopping >> obligation. > > Yeah, that's pretty much what I said above. > > http://wiki.openstreetmap.org/wiki/Proposed_features/compass > > I vote for highway=stop + compass=X on the way at the stop line plus > traffic_sign=stop + compass=X at the actual stop sign location. Why not use relations for stop sign applications similar to how enforcement relations work? It really seems silly to use a tag that expects people to imprecisely describe direction relative to four cardinal directions, or use degrees or radians, when you can essentially draw a picture. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
