Re: [Tagging] Billboard or something else

I'd go with traffic_sign=variable_message 223 uses on taginfo On Wed, Oct 30, 2019 at 7:51 AM Michael Brandtner via Tagging < tagging@openstreetmap.org> wrote: > Hi, > > I agree that advertising is not a fitting key. I could only find these: > > >

Re: [Tagging] Bus Routes PTv2

I always add it twice. The idea is to produce a relation that can be traversed start to finish the same way the bus does. On Thu, Sep 26, 2019, 13:37 James wrote: > If you have a bus route that doubles back on itself, do you have to add > the way twice to the relation or add it once and let the

Re: [Tagging] Bus routes tagging question

I had a route like that. Rather than create a variant, I used the opening_hours tag on that one stop. I can look it up if that would help. On Fri, Sep 20, 2019, 12:13 James wrote: > For bus routes I understand the whole concept of route and route_master > and you map multiple routes into

Re: [Tagging] Tourist bus stop

I believe that tourism is a characteristic of the line, not the stop. PTv2 handles this (as it does so many cases) quite easily. Here's an example in central Paris of a stop that is served by a "public" bus line and a "tourist" bus line: https://www.openstreetmap.org/node/5292142706 The tagging

Re: [Tagging] Using destination_sign relations for pedestrian navigation

*I wish to amend the Wiki to explain that destination_sign relations can also be used for pedestrian and indoor routing, not just at "crossroads". Does that require opening a discussion in the discussion page, or may I just go ahead ?* I think you're reading too much into the single word

Re: [Tagging] roads with many names

Don't know how you deduced "no space?" from Martin's comment. A space is an alphanumeric character. In any case, as I mentioned, there is normally a local consensus on space-versus-no space, and as others have mentioned, it's up to you. The problem with space-vs-no space arises particularly with

Re: [Tagging] roads with many names

Normally it would be "ref:usfs" rather than "usfs:ref". I frequently use tags like "ref:FR:STIF" where STIF is an agreed tag within FR (France). And yes, the main ref for the cited road would be "ref=CR 2". Included spaces in a ref tag vary by local consensus. Some places might use "ref=CR2". If

Re: [Tagging] Route sorting

Thanks Paul ... On Fri, Aug 16, 2019 at 2:13 PM Paul Allen wrote: > On Fri, 16 Aug 2019 at 11:56, Johnparis wrote: > >> Hoping this is on topic or close ... >> > > Drifting away. But you can fix that by saying you will vote against > certain proposals for > ro

Re: [Tagging] Splitting places and hosted devices in mapping

Thanks for the explanation. I see your point. On Sat, Jun 8, 2019 at 7:10 PM François Lacombe wrote: > Hi Colin, > > Le sam. 8 juin 2019 à 18:53, Colin Smale a écrit : > >> If we want to describe the overall transfer function of the whole >> "building", then we need to describe the input and

Re: [Tagging] Splitting places and hosted devices in mapping

ifies the output voltage in your example. As I read other related pages, I think it should be tagged: voltage:primary=63000 voltage:secondary=1500 Cheers, John On Sat, Jun 8, 2019 at 5:07 PM Johnparis wrote: > I agree with Marc that you should never "create nodes at a random posit

Re: [Tagging] Splitting places and hosted devices in mapping

I agree with Marc that you should never "create nodes at a random position with the equipment to avoid the tag for the characteristic". If you place a node, it should reflect as closely as possible the actual position, although if the position is uncertain, it's typical in OSM to place a node

Re: [Tagging] Splitting places and hosted devices in mapping

I believe the key phrase is "single-use" in the sentence you cite. That is, for instance, if you have a building that is a café (tagged as building=yes) with a node inside it with the details of the café (name=Rick's Cafe; amenity=cafe), then you should move the tags from the node to the area and

Re: [Tagging] Misuse of name tag for route description

First of all, what Mateusz is proposing as the "name" of the route is properly referred to as the "headsign". And the notion that because Mateusz thinks the "description" tag is a better fit than the "name" tag is all well and good, and merits discussion, but it doesn't mean he's right (or wrong).

Re: [Tagging] Misuse of name tag for route description

I agree with Martin. Often the bus itself has route maps, etc., inside the bus that have more information than can be displayed on the external sign. For bus routes, at least, there is an established convention for the name tag. I have mapped hundreds of such routes. It is definitely NOT a

Re: [Tagging] Extremely complicated conditional values

Apr 25, 2019 at 10:28 AM Johnparis wrote: > I'd try something similar to this example: > > access:conditional=destination @ (weight>5.5) > > So in your case you would have > > maxspeed:advisory:conditional=18 @ (weight>=37.5) > maxspeed:ad

Re: [Tagging] Extremely complicated conditional values

I'd try something similar to this example: access:conditional=destination @ (weight>5.5) So in your case you would have maxspeed:advisory:conditional=18 @ (weight>=37.5) maxspeed:advisory:conditional=22 @ (weight>=35 AND weight<37.5) maxspeed:advisory:conditional=26 @ (weight>=32.5 AND

Re: [Tagging] Feature Proposal - Voting results - Police facilites

Well, not sure how you define "police or military" force, but there is NATO, which overlaps with the EU, and Frontex, which is the EU border police. https://frontex.europa.eu/ Also, the Frontex page mentions the European Fisheries Control Agency (EFCA) and the European Maritime Safety Agency

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

Thanks. I never did post the final vote, which was 17 yes, 14 no, and 2 abstain. (There was an additional yes vote after the time period elapsed, which has no effect on the outcome.) The proposal was therefore defeated, not having achieved anywhere near 74% approval. I suspect that it is not

Re: [Tagging] Status of oneway=cw oneway=ccw

direction=clockwise/anticlockwise makes sense for a node (like a miniroundabout), not for a way on a way, the common usage is "oneway=yes" and make sure the way (which is by nature directional) is pointing the right direction. It doesn't make much sense for a hiking route to use "clockwise" (why

[Tagging] Feature Proposal - Voting - Mapping disputed boundaries

As promised, I have opened the Mapping Disputed Boundaries proposal for voting. Voting will be open until Feb. 10. https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries#Voting John ___ Tagging mailing list

[Tagging] Last call Re: Feature Proposal - RFC - Mapping disputed boundaries (Version 1.6)

I intend to put this to a vote starting next weekend, so please take a look at the proposal and discussion. https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Link roads between different highways type

I agree with you. For roundabouts and circular junctions, I use the highest type. For link roads, the lowest. I could see an exception for motorway onramps, indicating "starting here you can't get off the motorway". On Tue, Jan 15, 2019, 11:52 Saeed Hubaishan About the subject I used to

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.6)

control it anyway > > > It would be nice if the proposal can be extended to cover them. > > Also, among the existing list of example, for Shebaa Farms, the > claimed_by=* should also include Syria. For Israel-Palestine dispute, it > should also separately list out Area A/B/C for W

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.6)

Hi, Graeme, and thanks for the question. As I understand it (from reading the wikipedia article and others), each country controls its territory up to the cease-fire line. The zone is demilitarized, yes, but still policed. And if you cross the line, you'll be stopped by someone from the other

[Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.6)

I have just posted version 1.6 of my proposal on mapping disputed boundaries. It tightens the definition of the "controlled by" tag in an effort to improve verifiability. *Changelog* - *Version 1.6* - Defining terms for "controlled_by" tag to improve verifiability. - *Version 1.5.1*

[Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.4)

I have just posted another version 1.4 of my proposal on mapping disputed boundaries. It now includes maritime boundaries, thus minimizing changes from the current map (see the possible renderings page for illustrations). It also includes a changelog: - *Version 1.4* - Using maritime

[Tagging] Claiming Entities (was: Feature Proposal - RFC - Mapping disputed boundaries (Version 1.3))

Thanks, Fredrik, for breaking the ice on the List of Claiming Entities and the criteria for the list, which I think is one of the key points of my proposal. The list is logically equivalent to the stated criterion. That is, if you meet the criterion, you are on the list, and if you are on the

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.3)

Thank you for this thoughtful analysis, Fredrik. I will be incorporating many of these ideas in version 1.4. For one of them, the minimal boundary, I realized that it wasn't necessary, because it duplicates a zone of control. I came to this conclusion after your wrote your email but before I read

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.3)

heers, John On Sat, Dec 8, 2018 at 11:42 AM Andy Townsend wrote: > On 05/12/2018 18:52, Johnparis wrote: > > I have just posted another revised version of my proposal on mapping > > disputed boundaries. > > > > It greatly simplifies the tagging and relation st

Re: [Tagging] Salumeria(it) / charcuterie(fr) / Wurstwaren (de) WAS Re: Can OSM become a geospacial database?

ago. John On Thu, Dec 6, 2018 at 11:09 AM Dave Swarthout wrote: > I have no idea how to tag a shop selling *salumeri* but I do know that > shop=butcher and butcher=pork is totally wrong for a shop that sells cold > cuts. Johnparis is quite right that a butcher is someone w

Re: [Tagging] Salumeria(it) / charcuterie(fr) / Wurstwaren (de) WAS Re: Can OSM become a geospacial database?

Cold cut, in American English anyway, is any sliced meat that is packaged and sold chilled. Often pork based (ham and sausages like bologna are popular) but also other meats like turkey. shop=butcher + butcher=pork is what the wiki suggests. I personally think of a butcher as someone who slices

Re: [Tagging] Can OSM become a geospacial database?

Thanks, Michal. Following that link led me to: shop=butcher + butcher=pork which specifically mentions charcuterie. Presumably covers this too. Best, John On Thu, Dec 6, 2018 at 8:18 AM Michal Fabík wrote: > On Wed, Dec 5, 2018 at 10:03 PM Sergio Manzi wrote: > > I have the same problem

[Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.3)

I have just posted another revised version of my proposal on mapping disputed boundaries. It greatly simplifies the tagging and relation structure. Thanks to everyone who gave public and private feedback. I've archived some of the comments that are no longer applicable. The proposal is here:

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.2)

I have done some slight tweaking/reorganizing of the proposal page, mostly to separate out the rendering (which is not part of the proposal) from the tagging (which is). John On Mon, Dec 3, 2018 at 10:19 AM Johnparis wrote: > FYI, I have just added a few possible renderings: > >

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.2)

FYI, I have just added a few possible renderings: https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries/renderings John On Sun, Dec 2, 2018 at 6:23 PM Johnparis wrote: > I have just posted an extensively revised version of my proposal on > mapping di

[Tagging] Feature Proposal - RFC - Mapping disputed boundaries (Version 1.2)

I have just posted an extensively revised version of my proposal on mapping disputed boundaries. Thanks for everyone who gave public and private feedback. I've archived some of the comments that are no longer applicable, and of course I expect lots of new comments! There are several examples,

Re: [Tagging] Both proposals for disputed country borders

, with examples on the development server, this weekend. Take good care, John On Sat, Dec 1, 2018 at 1:15 PM Andy Townsend wrote: > (previous conversations heavily edited) > > On 28/11/2018 10:49, Rory McCann wrote: > > > > > > On 28/11/2018 06:39, Johnparis wrote: > >

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

hope to have the revised version (with examples) ready by the weekend. John On Wed, Nov 28, 2018 at 2:04 PM Johnparis wrote: > Thanks for that, Martin. This is explicitly covered in the proposal under > the List of Claiming Entities. The criteria for joining the list are >

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

Thanks for that, Martin. This is explicitly covered in the proposal under the List of Claiming Entities. The criteria for joining the list are crucial to implementation of the proposal. Palestine is on the list. Kurdistan is not. But once again, it's the criteria that count. On Wed, Nov 28,

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

different points of view. John On Tue, Nov 27, 2018 at 1:20 PM Johnparis wrote: > Thank you for that reference, Marc. > > The blog post you cite deals with the policy and how it is enforced, not > with the question of physical control. The blog acknowledges that Russia > has phy

Re: [Tagging] My proposal for disputed country borders

Thanks for this, Rory. I'll add it as a comment to the active proposal ( https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries ). I don't think the notion of "according_to" is viable unless it is restricted to the two disputing parties. (Three-way disputes can be

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

ould lift one burden from them!) This proposal would remain the same. John On Tue, Nov 27, 2018 at 10:20 AM Marc Gemis wrote: > On Tue, Nov 27, 2018 at 10:06 AM Johnparis wrote:\ > > > The question of "physical control" is, I believe, not at issue. The fact > that Russia exerc

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

elaborate how we would map the situation to the satisfaction > of both groups ? > > m > > On Tue, Nov 27, 2018 at 8:30 AM Johnparis wrote: > > > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries > > > > On Tue, Nov 27, 201

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

And here are links to the two main Talk threads that most recently raise this subject: https://lists.openstreetmap.org/pipermail/talk/2018-November/081683.html https://lists.openstreetmap.org/pipermail/talk/2018-November/081723.html On Tue, Nov 27, 2018 at 8:28 AM Johnparis wrote: > >

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries On Tue, Nov 27, 2018 at 4:31 AM Daniel Koć wrote: > W dniu 27.11.2018 o 03:21, Johnparis pisze: > > A general proposal to address mapping disputed borders at the national > > level. > &g

[Tagging] Feature Proposal - RFC - Mapping disputed boundaries

A general proposal to address mapping disputed borders at the national level. I've read the discussions on the Tagging and Talk lists, and have given the matter considerable thought (and experimented with different approaches) before formulating the proposal. I hope it offers a mechanism to show

Re: [Tagging] visa offices tags

I tagged one of these office=visa the other day. https://www.openstreetmap.org/node/4374770543 The offices I'm thinking of are private companies that have government contracts to provide services that the government itself would normally provide. In many cases they are indistinguishable from a

Re: [Tagging] Feature Proposal - RFC - (consulate)

OK, I take back what I said. And if Allan, Markus and Martin all think that's the way to go, I'm fine with that. On Thu, Nov 1, 2018 at 9:46 AM SelfishSeahorse wrote: > On Thu, 1 Nov 2018 at 09:41, Martin Koppenhoefer > wrote: > > > > > I haven't seen anyone (recently) who supports your

Re: [Tagging] Feature Proposal - RFC - (consulate)

I haven't seen anyone (recently) who supports your original proposal of keeping amenity=embassy and adding amenity=consulate. So I believe your first summary is inaccurate. Instead what I have seen is suggesting that amenity=diplomatic is possibly a better fit than office=diplomatic. So I would

Re: [Tagging] Feature Proposal - RFC - (consulate)

The problem I see is that, as I understand it, Allan is proposing to drop some existing diplomatic=* values, such as diplomatic=permanent_mission. And the proposed substitute is to rely on the name=* tag. Martin pointed out a problem where something not an embassy has a name like an embassy. But

Re: [Tagging] Feature Proposal - RFC - (consulate)

I was waiting for Martin to weigh in on the amenity vs. office question. To me, a consulate falls squarely within the definition of amenity. It certainly serves "tourists" (including expats/foreigners/etc.). When I am visiting a new country, my country's consulate is one of the most important

Re: [Tagging] Feature Proposal - RFC - (consulate)

Thanks for refocusing the discussion, Martin. I think the new tag should be amenity=diplomatic. A major reason is the instance where both an embassy and a consulate share a node. If the new tag is amenity=consulate, you would either need two nodes in the case where they share a space, which is

Re: [Tagging] Feature Proposal - RFC - (consulate)

I believe there is already a list of embassy types on the wiki : https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dembassy#Types_of_embassies You might want to verify/expand as needed. On Tue, Oct 23, 2018 at 3:58 PM Allan Mustard wrote: > Please continue to comment on this proposal: > >

Re: [Tagging] Feature Proposal - RFC - (consulate)

nity=consulate > On Mon, Oct 22, 2018 at 7:42 AM Warin <61sundow...@gmail.com> wrote: > >> On 22/10/18 09:09, Martin Koppenhoefer wrote: >> >> > >> > sent from a phone >> > >> >> On 21. Oct 2018, at 19:20, Johnparis wrote: >> >

Re: [Tagging] Feature Proposal - RFC - (consulate)

To answer the question from Mateusz, most consulates have a plaque outside with the name, such as "Consulat de Mali", and they are physically separate from the embassies even in cities (like Paris, where I live) where a country might have both (such as the USA does). Question : there is existing

Re: [Tagging] Traffic sign direction tagging..

Thank you for this, Bryan. One small favor: could you add a "Change direction" button like you have for one-way streets? It makes it much easier if I guess wrong :) On Fri, Sep 28, 2018 at 6:58 PM Philip Barnes wrote: > > > On 28 September 2018 17:31:18 BST, Kevin Kenny > wrote: > >On Fri,

Re: [Tagging] Designated value as a key

I said "for example." Taginfo has 2716 different values for the "access" key, only a few of which are documented. On Sun, Sep 9, 2018 at 11:48 PM Martin Koppenhoefer wrote: > > > sent from a phone > > On 9. Sep 2018, at 14:53, Johnparis wrote: > >

Re: [Tagging] Designated value as a key

I agree that it is theoretically a problem for the software not to use access:bicycle=yes (for example) instead of bicycle=yes. I believe I've seen (from Thorsten?) a list of such tags, as a hierarchy. https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation Data consumers always

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

*Daniel McCormick wrote: "I propose that only one language is used for the name= tag"* This fails immediately in bilingual countries like Belgium, and also fails in countries like Morocco, where the predominant language is Arabic, but the two legal languages are Arabic and Tamazight, while a

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

Osmose generates an error if you use a slash. I don't see consistency as an advantage. It's a local decision. If the names use different writing systems (as in the HK example) a space is sufficient. Slashes do occur in names, but surely more rarely than embedded hyphens. I think the spaced

Re: [Tagging] [OKFILTER] Public Transport v3 — starting RFC

This is a very long and complex proposal, so it will take me a while to digest and respond. I am also alerting the transport mailing lists in English and French. I trust the RFC will be open for at least for a couple of months. Cette proposition (en anglais) est très longue et complexe, il me

Re: [Tagging] esperanto=yes

I was going to suggest the same as Eric. Best to use the ISO codes for the languages (though I think maybe the three-letter codes are better) and to use language as the prefix. On Thu, Jun 28, 2018 at 4:30 PM, wrote: > Hi, > > > > language information could be an interesting tag for tourist

Re: [Tagging] tagging bicycle charging stations

You don't need to include all the "no" values, I'd say. Just tag what you see (not what you don't see). amenity=charging_station charging:bicycle=yes On Wed, Jun 27, 2018, 20:39 Max wrote: > On 27.06.2018 17:39, marc marc wrote: > > Le 27. 06. 18 à 16:28, Paul Allen a écrit : > >> On Wed, Jun

Re: [Tagging] PTv1 <> PTv2

It has become rarer because of PTv2. There is no distinction in PTv1. On Mon, Jun 25, 2018, 01:24 Martin Koppenhoefer wrote: > 2018-06-24 1:20 GMT+02:00 marc marc : > >> Hello, >> >> Le 22. 06. 18 à 15:37, Martin Koppenhoefer a écrit : >> > is there a benefit from it? >> >> try to map a

Re: [Tagging] public_transport=platform rendering on osm-carto

Most folks do use presets, especially those marking bus stops in the wild, which is the vast majority of the cases that matter in this discussion. Only recently (March 2018) did iD begin including PTv2 tags in its presets. Before then, it only offered PTv1, that is, highway=bus_stop. So of course

Re: [Tagging] public_transport=platform rendering on osm-carto

wrote: > > > sent from a phone > > > On 22. Jun 2018, at 13:53, Johnparis wrote: > > > > It's not always a waiting area, btw, sometimes it's reserved for leaving > the transportation device. > > > the definition for public_transport=platform is “The place wh

Re: [Tagging] `amenity=shelter` implies `building=yes`?

Agree with the notion that building is implied. In France, public transit shelters are often included in the cadastral information, and they wind up being tagged as building=yes + wall=no (through the import) or as building=roof (after verification).

Re: [Tagging] Feature Proposal - RFC - Lounges

this is precisely why I raised the question of whether a lounge is an amenity. it's not open to the general tourist population, for example, like a bank or a pharmacy. On Sun, Jun 10, 2018 at 6:04 PM, Paul Allen wrote: > On Sun, Jun 10, 2018 at 4:16 PM, Yves wrote: > > Given the definition

Re: [Tagging] Feature Proposal - RFC - Sauna

You might (or might not) want to reconcile this with https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bath On Sun, Jun 10, 2018 at 3:19 PM, Jyri-Petteri Paloposki < jyri-petteri.palopo...@iki.fi> wrote: > On 10.06.2018 16:14, osm.tagg...@thorsten.engler.id.au wrote: > > If you are

Re: [Tagging] Feature Proposal - RFC - Lounges

I would think hotel lounges don't qualify, then, under what you're describing. I've never seen one that offers showers. Hotel lounges are just alcoholic bars in a hotel. You want a shower, you have to check in to the hotel. As a node or area (room?) within a public_transport=station, it makes

Re: [Tagging] The endless debate about "landcover" as a top-level tag (was: Re: British term for municipal greenery?)

landuse=forestry seems a logical choice. On Wed, Jun 6, 2018, 17:38 Mateusz Konieczny wrote: > > > > 6. Jun 2018 17:10 by kevin.b.kenny+...@gmail.com: > > So we have available to us: > > landcover=trees - seldom used, but available and unambiguous > natural=wood - controversial, what qualifies

Re: [Tagging] new role for route relations: reverse

Not a bad suggestion, but I think the point is that the driver uses reverse gear. The route should validate just fine, at least in JOSM. The question is whether others will stomp on it, which is precisely what the note=* tag is for. You could add it to the route itself, not just the way, if you

Re: [Tagging] new role for route relations: reverse

Replying specifically to this point: *Sure, renderers and routers might cope with the bus going to point X and magically* *switching its direction of travel by 180 degrees but it's a bit puzzling for dataconsumers. Does the bus go out of service there? Is it a terminus? Has the mapper*

Re: [Tagging] how to tag place where horse-drawn carriages wait for tourists?

>What about electric vehicles that offer very similar services - trip across city. A taxi? Seriously I don't know what you mean. I have seen similar services (tuk tuks) but they're not exclusively for tourists. On Fri, May 25, 2018, 19:57 Erkin Alp Güney wrote: >

Re: [Tagging] how to tag place where horse-drawn carriages wait for tourists?

As I read the tourism=* page, it seems that tourism=attraction is for things (like waterfalls) that exist independent of tourism that might interest a tourist. Things like theme parks that exist only for tourists would get a tourism=* tag. So I suggest tourism=carriage_ride as the main tag. I

Re: [Tagging] roundtrip

I would generally agree with all your points. A slightly more formal definition (though not fully rigorous) for me would be: a circular route is one in which, from any boarding area, you can return to the same boarding area without being forced to disembark. I say boarding area rather than point

Re: [Tagging] roundtrip

Interesting. Similarly, a route that is not closed can be a roundtrip. The start and end points might be several meters apart, even on different roads, yet serve the same destination. There are a few (very few) examples I have found in the Paris area. Here's one. It's not marked roundtrip=yes but

Re: [Tagging] tagging of one-way cycle lanes

Back to this again, Paul. It is getting tiresome. If you don't like how the tag is defined, create a new one. Don't vandalize the old one. The *:lanes suffix is unrelated to the lanes=* tag. Get over it. On Sun, May 13, 2018 at 8:26 PM, Paul Johnson wrote: > On Sun,

Re: [Tagging] [OKFILTER] Re: tagging of one-way cycle lanes

+1 Thanks, Marc. Simpler is better :) On Sun, May 13, 2018 at 8:21 PM, Marc Gemis wrote: > I would just map them as lanes =2; cycleway=lane. That is how they are > mapped in Belgium and The Netherlands. > Isn't that the L1a case of >

Re: [Tagging] [OKFILTER] Re: tagging of one-way cycle lanes

Thorsten's initial suggestion is the agreed-upon method, not PJ's. https://lists.openstreetmap.org/pipermail/tagging/2018-May/036178.html Instead of oneway=yes and oneway=-1, use :lanes:forward or :lanes:backward in the key. And as many have pointed out, don't touch the main "lanes" tag, which

Re: [Tagging] access=disabled

If it's exclusive the normal tagging would be: access=no disabled=yes ...to be consistent with other such, like access=no bus=yes Though I would argue that they all should use the access: prefix in this case access=no access:disabled=yes On Thu, May 10, 2018, 02:51 Andrew Davidson

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

PLEASE do NOT create a highway=walking_bus tag! This would be useful for the Public Transport v1 scheme. Which hopefully will some year go away. Please DO follow Thorsten's suggestion and follow PTv2, mapping the stops as nodes alongside the street/way (not on it) in the proper direction. Tag

Re: [Tagging] [OKFILTER] Re: Mapping generic sheds

I agree with you, Dave, about "shed roof", but I have very often seen/heard the term "shed" used regardless of the type of roof in the USA. On Fri, May 4, 2018 at 8:49 PM, Dave Swarthout wrote: > Let me make just one additional comment. > > In the U.S. we hear the term

Re: [Tagging] Unclear meaning of amenity=bus_station

Ah, good, the Moroccan photos were quite a mish-mash. The one you just posted is indeed a bus station. And sort of a classic one at that -- it has both intercity and regional lines (lines that extend well beyond the city limits but aren't long-distance lines). Also, intracity lines have stops in

Re: [Tagging] Unclear meaning of amenity=bus_station

Your point about stopping in traffic is a good one, and it dovetails with the notion that a bus station (amenity) normally includes one or more dedicated bus lanes. Perhaps that can be added to the wiki. Smaller places and/or transfer points are well covered by the Stop Area concept, which the

Re: [Tagging] Unclear meaning of amenity=bus_station

Not quite sure what you mean by "importance lower than railway=halt". A halt is a place where a train doesn't normally stop unless a would-be rider hails it. A bus stop that is so minor would certainly not qualify as a bus station, and I don't think it would fit the definition in the wiki unless

Re: [Tagging] Still RFC — Drop stop positions and platforms

One point that hasn't been discussed (and isn't in the subject line) is that part of Ilya's proposal is to also drop stations. I would move in the opposite direction and expand the role of stations. Here's why. In many (many) cases, GTFS data from bus operators includes a single StopPoint value

Re: [Tagging] Still RFC — Drop stop positions and platforms

I independently reached a conclusion similar to Jo's. No need for a separate tag; the difference is made clear when you look at whether it's a node, way or area. And there are lots of optional tags to indicate structural elements like benches, shelters, tactile pavement, etc. I don't usually go

Re: [Tagging] Still RFC — Drop stop positions and platforms

Heh, never noticed that. iD is now automatically putting bus=yes on the platform node, which seems clearly correct. The proposal page should be amended, I think. On Thu, Mar 29, 2018 at 12:33 PM, Selfish Seahorse < selfishseaho...@gmail.com> wrote: > > It seems that one major issue was that,

Re: [Tagging] Still RFC — Drop stop positions and platforms

Thanks for that last point, Christian. Always good to read the documentation! The English version (emphasis mine) reads: These 'traditional' tags are still widely used and are not invalidated by this scheme and ***should be kept*** in order to ensure compatibility with legacy software, at the

Re: [Tagging] Historic building usage

Interesting. Musée d'Orsay in Paris offers another possibility: building=disused:train_station https://www.openstreetmap.org/relation/2853923 ... as well as tourism=museum (reflecting the current use) On Thu, Mar 29, 2018 at 12:02 AM, Tom Pfeifer wrote: > On 28.03.2018

Re: [Tagging] Still RFC — Drop stop positions and platforms

I have spent some time reading https://github.com/gravitystorm/openstreetmap-carto/issues/435 and https://github.com/gravitystorm/openstreetmap-carto/issues/331 It seems that one major issue was that, given a simple public_transport=platform situation, which icon should be used to render it? In

Re: [Tagging] Still RFC — Drop stop positions and platforms

>> Add relations and direction of ways (forwards, backwards) and it's a very time consuming task to upgrade v1 to v2, especially if bus routes change. > Do you mean 'forward' and 'backward' roles? I think what was meant was that in v2 you want to create a forward relation and a backward

Re: [Tagging] red housenumbers

In the case of Florence, as I understand it, the red numbers originally denoted businesses, while the black/blue numbers were for residences. It appears that they use the numeral followed by a space then a capital R, thus 49 R for number 49 rosso.

Re: [Tagging] Tagging fraction house numbers?

I think Google, at least, is aware of it and made a decision not to use the ½. In another project, I gained some experience with their mapping API, and the lack of ½ (and bis, etc.) caused some headaches when trying to geocode addresses. For your example, trying to resolve 40½ Rue de Carillon

Re: [Tagging] discrepancy in shop definition and "wholesale" value

wholesale=* (not wholesaler=*) is in the never-approved shop=wholesale proposal and has 677 usages. https://taginfo.openstreetmap.org/keys/wholesale#values Perhaps a wiki entry for wholesale=* is needed, with cross-references between that and shop=wholesale On Tue, Mar 6, 2018 at 6:55 PM, Paul

Re: [Tagging] discrepancy in shop definition and "wholesale" value

Regarding Althio's comment: This is exactly the sort of confusion caused by using the word "wholesale" in shop=wholesale. These are not wholesalers. They are retailers who use the word "wholesale" as a marketing tool. (Even if the parent company has wholesale activities, these particular

Re: [Tagging] discrepancy in shop definition and "wholesale" value

Must agree with Thorsten and Stefano. The proposal referenced by Martin is just that: a proposal. From 2011-12. Never approved. The wiki page (created 2015) makes clear that the actual key, in use, refers to shops like Costco, which btw is the same in the US as the Australian version. See also

Re: [Tagging] [OKFILTER] Re: [OKFILTER] Re: "service" tags in general (for shops)

fyi, I looked at the 100-odd Cartridge World shops around the globe. They are mostly listed as shops, with the most popular being: computer 25 stationery 15 printer_ink 9 No ringing endorsement there. On Tue, Feb 27, 2018 at 2:53 PM, John Freed wrote: > i see

Re: [Tagging] [OKFILTER] Re: [OKFILTER] Re: "service" tags in general (for shops)

Yes, it's certainly in general use. And its page marks "shop=printing" as a tagging error. So I decided to read the documentation about shop vs amenity, and apparently some shops are marked as amenities if they are useful for tourists, which I guess a pharmacy is and a chemist isn't. And estate

  1   2   >