Re: [Tagging] lanes - is "parking allowed" a parking lane?

tion (criteria #1) need the information how many lanes are tagged. So, I am going ahead an will add these two words to the documentation of the lanes key. Cheers Tobias On 20/11/2020 14:03, Tobias Zwick wrote: You stated how you would tag that, which I'd summarize as > Any parking on the

Re: [Tagging] surface=rock

> rock „pieces“ would be tagged as „stone“ I guess? Not so sure about that, then it would be surface=stones, (note the plural) wouldn't it? --- There is a huge discussion on the #tagging channel on OSM slack (85+ replies) where all those "rocky" surface are being discussed. Here are some

Re: [Tagging] lanes - is "parking allowed" a parking lane?

You stated how you would tag that, which I'd summarize as > Any parking on the street surface is subtracted from the lanes as the > lanes-tag first and foremost indicates the number of usable lanes, not > the number of marked lanes Ok, so apparently there is no consensus on that if there are

Re: [Tagging] lanes - is "parking allowed" a parking lane?

rking cars. Tobias On 19/11/2020 23:22, Graeme Fitzpatrick wrote: On Fri, 20 Nov 2020 at 00:22, Tobias Zwick <mailto:o...@westnordost.de>> wrote: https://westnordost.de/misc/2or1lanes.jpg <https://westnordost.de/misc/2or1lanes.jpg> It is a residential road marked

Re: [Tagging] lanes - is "parking allowed" a parking lane?

gally park there then I'd include it as lanes=* and also tag parking:lane. It's common that during peak hour the lane is used by traffic, but off-peak it's available for parking. On Fri, 20 Nov 2020 at 01:22, Tobias Zwick <mailto:o...@westnordost.de>> wrote: Hello all First of a

[Tagging] lanes - is "parking allowed" a parking lane?

Hello all First of all, in the past, we have explored many edge cases for the lanes-tag in various discussions and I am happy that for the most part, it seems to be quite well defined by now. However, there is one edge case which is not uncommon at all but still unclear or awkward to tag.

Re: [Tagging] OSM changes the world | Re: Feature Proposal - RFC - Artificial

The purpose of OSM is to **map** the world. If this brings about positive change such as the things you mentioned (any many more), that's good and that is the reason why many people contribute to such a free wiki world map. This is a huge difference to your statement! You seem to defend that

Re: [Tagging] "width" on streets: Time for a recommendation

>To me it seems obvious that width values, independently on how they are >measured, are at best estimates, as measuring them is in most cases >dangerous or requires good technical equipment. I don't think this is true anymore. Did you try out "Measure" or any other ARCore/ARKit-based measuring

Re: [Tagging] "width" on streets: Time for a recommendation

Absolutely high time! Thank you for bringing this up. I was under the impression that the wiki already defined it like 2). 1) is not practical because parking lanes can be informal or can change quickly, 3) is also not practical because sidewalks + additional greenery/space between road and

Re: [Tagging] tagging drinking water of uncleaer official (signed) status

The discussion went astray a bit, partly because I think it was not clear why Mateusz proposed to use the drinking_water:legal=yes/no/unknown at all, if there is already the tag drinking_water=yes/no. Let me illustrate with some examples. So, these two cases are clear: * 1. There is a sign

[Tagging] StreetComplete: summary of re-survey quests and how they will be tagged

Hi there, for your information, here is a summary of all re-survey enabled quests with intervals, element selection and notes what will be tagged now: https://github.com/westnordost/StreetComplete/issues/1998#issuecomment-677825912 Cheers Tobias ___

Re: [Tagging] StreetComplete: no re-survey for speed limits

I am not sure what is the message of your statement. Is this just a general opinion regarding speed limits or is this somehow referring to the explanation I linked in the thread starter? If the latter, and you think after all it would be possible to implement such a re-survey for speed limits

[Tagging] StreetComplete: no re-survey for speed limits

Hey guys, I just wanted to inform you that unfortunately, StreetComplete will not offer a re-survey for speed limits in the upcoming "Map Maintenance with StreetComplete" feature but probably never anyway. Short explanation: It is impossible to implement a re-survey without creating conflict

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

Two more types came to my mind: 1. Courtyard area (Дворовая территория) Another type of service road that is currently probably not tagged with any subtag came to my mind right now: Something like a multi-use courtyard area bounded by buildings around the

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

> For the second type of highway=service with no service tagging, what > about using service=access?  The issue with this is that basically this is the definition of highway=service already without any extra tags: It provides access to something. Be it the rear/side of buildings (alley), the

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

service=parking_access also sounds most clear to me. On the other hand, service=parking is already used almost 2000 times so documenting that as "main access road in a parking" would just be documenting the status quo, no proposal necessary, which is certainly easier. IF after research one can

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

>  - Roads through cemeteries >  - Roads through campgrounds >  - Roads through schools >  - Roads through universities >  - Roads through hotels >  - Roads through museums >  - Roads through prisons >  - Roads through military areas >  - Roads through airports >  - Roads through retirement homes

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

> I think it would help with community acceptance of a potentially large > number of meta tags if you're somewhat frugal when it comes to adding > new ones. [...] > > In practice, this could mean ... > > * ... not adding key:check_date when the key is first added, or when the > value is changed

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

> adding check timestamps as string tags for every single tag seems a lot of > bloat. One tag per object for me would be acceptable because it is indeed a > valuable information when something was last verified and no changes were > necessary. Definitely it has the potential for that. And as

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

Thanks! > Secondly, I think having to evaluate the history is a challenge. But do > you have to?  No, I don't have to, thanks to such tags as check_date. But then again, check_date, survey:date etc. only came to be invented because API support was missing. It would be better to have somthing

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

> It is completely possible to add this functionality to the API in a > backwards compatible fashion, at the cost of a long per tag in the > current table (assuming that we don't need the information for historic > object versions, so at a reasonable cost space wise. There are a couple > of

[Tagging] Map maintenance with StreetComplete - Preferred tagging

Hello everyone As you may or may not know, my microgrant proposal "Map maintenance with StreetComplete" [1] was selected to be funded by the OSMF. So, I am happy to have the oppurtunity to invest the time extending the app, hoping that it will help to keep the map up-to-date and unburden people

Re: [Tagging] Discourage use of landuse=churchyard?

It could be useful to check (at random) how the tag is currently used - as synonym for graveyard, or for religious or both, at times (-> tag is ambiguos) and put that info in the wiki as well. If it's both as you suspect, it's a very good reason to point to the other tags instead. Tobias Am

[Tagging] Tagging of bicycle anti-features

We know how to tag certain bicycle features such as the "advanced stop line" [1] It would be interesting to tag also anti-features. Most commonly, a cycleway that just ends without merging it back onto the street. Currently, such a situation would be tagged the same as a track that is merged

Re: [Tagging] How to tag pedestrian lanes?

gt;rather than calling these a type of sidewalk > >- Joseph Eisenberg > >On Mon, Oct 21, 2019 at 3:51 PM Mateusz Konieczny > wrote: >> >> 20 Oct 2019, 19:08 by selfishseaho...@gmail.com: >>> >>> On Sun, 20 Oct 2019 at 12:42, Tobias Zwick >wrote: &g

Re: [Tagging] How to tag pedestrian lanes?

I have seen this kind of sidewalk that is just a marked lane in Germany as well, usually as part of parking lots or larger company grounds. How about: sidewalk=right sidewalk:right:kerb=no sidewalk:right:surface=asphalt The most important thing is to tag whether there is a sidewalk or not.

Re: [Tagging] Guard booth building type

How about porters_lodge, it's more general. It would cover the small building at the entrance of outdoor pools where you buy the tickets, same for other outdoor venues, the booth at the entrance of company/factory grounds, the guard booth at the entrance of gated communities etc. Not sure if

Re: [Tagging] New tag proposal: 'addr=milestone'

Milestones are not necessarily located at the true distance of A to B. Not sure why this is the case, but I know that this is true for at least Thailand. On 01/10/2019 21:10, Paul Allen wrote: > On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre > wrote: > > The

[Tagging] Tagging meadow orchards

Hey there What is the best way to tag meadow orchards? Most orchards are plantations with monocultures of one kind of tree, usually planted in rows and pruned to have a short trunk for easier picking. There is another type of orchard, in German "Streuobstwiese", in English I think "meadow

Re: [Tagging] oneway street with two combined foot-cycle lanes

Hi Volker The full tagging here would be: oneway = yes oneway:bicycle = no <- oneway not for bicyclists sidewalk = both <- there is a sidewalk on both sides cycleway = track...which is also a cycleway and cycleway:segregated = no

Re: [Tagging] lanes = 0

Also, the mention of that lanes key (should) only be used to denote the number of MARKED lanes was added in 2017 after a short discussion in the German forum about the same topic. However, in this topic here on the ML, arguments were brought forth that made us get to a different conclusion

Re: [Tagging] lanes = 0

This topic again? We had this just a few weeks back and we actually reached to a conclusion that lanes=0 should NOT be used to denote that there are no marked lanes. I believe I also documented that conclusion on the wiki, prompting here for review. Tobias On July 30, 2019 1:19:32 PM

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

Sounds to me that those pages were incorrectly deleted. Only because someone can tag the abandonedness of a single tag of a feature, doesn't mean that the tag that applies to the whole feature is deprecated. Actually, sine best practice is to map each feature as an own element (unless maybe

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

One or several wiki edits should stand at the end of every tagging discussion, to document the conclusions made. Tobias On July 29, 2019 8:37:25 AM GMT+02:00, Warin <61sundow...@gmail.com> wrote: >Err .. sent to tagging list, so response here. Not to worry, a little >more chatter. >(Should

Re: [Tagging] shop=window(s) incorrectly deprecated in favor of craft=window_construction ?

I always thought that there is no norm for standard sizes of windows, so every window is made to measure. (And in case of a larger construction project, then 1000s of windows are made with the same measure) Is this not true after all? Tobias On July 9, 2019 4:54:59 PM GMT+02:00, ael via

Re: [Tagging] Maxweight wiki page changes

s On 06/07/2019 14:17, Martin Koppenhoefer wrote: > > > sent from a phone > >> On 6. Jul 2019, at 12:53, Tobias Zwick wrote: >> >> So "unladen" is the word used in UK legislation? Do you have a link? >> Even if "unladen" is most commonly used i

Re: [Tagging] lit=yes/no threshold

> I am trying to make lit=yes/no definition more precise I think that your suggestions would make the definition actually less precise because they add a fair level of subjectiveness: "necessary to bring your own light" The least subjective definition is to map the physical presence of street

Re: [Tagging] Maxweight wiki page changes

>Unladen weight is used in European countries to apply only to goods >vehicles, either 3.5t or 7.5t, and is tagged as hgv=no/destination. Are you absolutely sure about this? I am pretty sure myself that hgv are defined differently: as goods vehicles with a "gross vehicle weight rating" (gvwr),

Re: [Tagging] Maxweight wiki page changes

So "unladen" is the word used in UK legislation? Do you have a link? Even if "unladen" is most commonly used in UK, I still find "empty" better because it is easier to understand what it means for non native speakers (simpler word). In the US, "empty" seems to be most commonly used, as it is

Re: [Tagging] Maxweight wiki page changes

Reviewed it. That is some impressive work, thank you for this! A few remarks: 1. Maxweight 1.1 At the examples: for max empty weight, I propose the key maxemptyweight. It suggests itself. 1.2 At the examples: Conditionals should maybe better be catch-all, so i.e. axles>=3 instead of axles=3

Re: [Tagging] New sections added to "Good Practice" page?

Maybe mobile-but-usually-stationary (or with a fixed schedule) amenities and shops could get an extra tag to denote that property. For example mobile=yes or something. POIs with this tag set could be resurveyed more often than others. Tobias On July 1, 2019 11:15:32 AM GMT+01:00, Paul Allen

Re: [Tagging] paid ferry - fee or toll tag

Colin Smale, this is a very wise thing to say. I think this is often a missing element in tagging discussions. Is there a tagging suggestion guidelines page on the wiki? If yes, this is definitely one point that should be added. And if not, maybe we (people on the mailing list) should create

Re: [Tagging] lanes = 0

Okay, to wrap this up, I added this title in the wiki and referenced back to this discussion, advising to not use lanes=0/1.5/none to signify no lane markings but instead use something like lane_markings=no. https://wiki.openstreetmap.org/wiki/Key:lanes#No_lane_markings --- Additionally, I

Re: [Tagging] shop=cannabis including medical cannabis

Wouldn't medical cannabis be sold in pharmacies? On 14/06/2019 18:26, Jmapb wrote: > An accepted answer to a recent question on help.openstreetmap.org ( > https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary > ) suggested expanding the definition of

Re: [Tagging] lanes = 0

lanes tag but on the other hand is used a few times already and is safe for the "_" instead of the ":" what Warin suggested 4. lanes:mark...=no would maybe imply that lanes=X must be tagged as well? On 13/06/2019 15:15, Tobias Zwick wrote: >> I think a tag to say "lane:marki

Re: [Tagging] lanes = 0

> I think a tag to say "lane:marking=no" could be better for that situation??? 1. or lanes:marked=no? (mark_ed_ instead of mark_ing_) Would be (more) consistent with the naming of opening_hours:signed, collection_times:signed, (1k-2k usages each) 2. or nolanes=yes? Would be consistent with

Re: [Tagging] lanes = 0

> Here, legally, if there are no lane makings then it is considered to have one > lane in either direction. I am kind of a fan of lanes=0, denoting that there are no marked lanes. Here is why: a. if a road with no lane marking is tagged as lanes=2, this situation cannot be distinguished from

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

Sorry in hindsight I should have left out the last paragraph, please ignore it. I would rather not discuss concrete suggestions for software but collect ideas for certain modes of communications that may make constructive communication happen more. On 25/05/2019 02:28, Tobias Zwick wrote

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

y) and Kotlin (modern programming language) both use Discourse. Could this be an option to replace both the mailing lists and the forums? https://www.discourse.org/ I am talking about replace here, because one part of the problem is, is that the community is so scattered ("filter bubbles"

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

> Sometimes, it goes the other way - the good way. There's consensus, or if > disagreement, the different options are offered constructively. You can see > that happen pretty often. How do we make that happen more? The discussion pretty quickly drifted from considering technical solutions to

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

These are some valid points, and I also have some input to that, but are you sure you want to discuss this on the tagging ML? The talk ML might be a better spot for this, this topic has already strayed quite far from the original topic. (And maybe start the topic on a more positive prospect

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

I'd say so. On 23/05/2019 19:03, Nick Bolten wrote: > So would it be fair to say that a linear *=platform implies foot=yes and can > be tagged with reasonable tags for a footway such as width, incline, surface, > tactile paving, etc? > > On Thu, May 23, 2019, 9:46 AM Tobias Z

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

"Redundant" is perhaps not the best way to describe the problem. I'd go about this like this: A "highway=footway" is a footway, a "public_transport=platform" is a bus stop (platform). These are simply two different things. They *share* certain properties, for example, they are accessible both

Re: [Tagging] ID is not a king and final arbiter of OSM (was: iD adding highway=footway to all railway/public_transport=platform ways and relations)

I simply have the feeling that we are heading straight for an escalation course here. I already see it looming that some day the plug might be pulled on iD (being hosted on openstreetmap.org) and I really really don't want this to happen, lest even to think about it makes me sick. Undoubtedly,

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

I like your wording. It is a burden. He also takes all the complaints for bugs and when iD steps on someone's shoes. This is a very stressful position to be in. Am 23. Mai 2019 09:38:06 MESZ schrieb Martin Koppenhoefer : > > >sent from a phone > >> On 23. May 2019, at 09:21, Mateusz Konieczny

Re: [Tagging] Extremely complicated conditional values

Even shorter, because if there are conflicting rules in the conditional, the last one is taken, says the wiki. (Not sure if this is really implemented in applications that work with that data though): maxspeed:advisory:conditional=37 mph @ (weight>=6 lbs);26 mph @ (weight>=65000 lbs);22

Re: [Tagging] Intermittently unprotected cycle track

Hi Richard I'd tag this situation with cycleway=track/lane/shared_lane on the road itself. I don't see the namespacing as an issue here. The rule of thumb I (we?) use to decide whether a cycleway shall better be tagged as a separate way is to look if the cycleway is segregated from the road

Re: [Tagging] Is there any use of shop=general/general_store not covered by shop=convenience/supermarket/country_store?

Well, there is a long wp article about it with a clear description for a start. From that I understand, general stores are tiny department stores - i.e. a hyper market is to a convenience store as a department store is to a general store. As it is about what they are selling, not where they

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

Missed the earlier discussion. I also always regarded cycleway=opposite, opposite_track, opposite_lane, opposite_share_busway etc. as the old deprecated method and oneway:bicycle=no + normal cycleway tag as the one that superceded it. Same with cycleway:right=dual_lane/dual_track being

Re: [Tagging] shop=clothes vs shop=fashion

Hmm, basically all kiosk type shops around my area are big enough to be entered - but only sell newspaper, magazines, cigarettes, drinks and snacks. But *not* any of toilet paper, shampoo, cornflakes, yogurt, bread (so, daily needs) iirc I think what they sell is a more useful differenciation

Re: [Tagging] shop=clothes vs shop=fashion

kiosk and convenience is supposed to be the same? I always used it like - convenience: small supermarket that is usually too small to have shopping carts but still also sells things of daily need (shampoo, toilet paper, milk, cornflakes, bread and spread,...). The typical 7-Eleven store

Re: [Tagging] What is a conscription number (addr:conscriptionnumber)?

Thank you for the documentation. I read it, and it is clear to me. Maybe it'd be good to further stress out how housenumber relates to conscription- and streetnumber by giving an example: addr:streetnumber + addr:street = addr:housenumber + addr:street addr:conscriptionnumber + addr:place =

Re: [Tagging] StreetComplete 10 / foot=yes on residential

Because this is about foot=no, not handcart=no On February 17, 2019 11:23:46 PM GMT+01:00, Martin Koppenhoefer wrote: > > >sent from a phone > >> On 17. Feb 2019, at 22:39, Tobias Zwick wrote: >> >> No, that tag is correct. It is not allowed to walk in the

Re: [Tagging] StreetComplete 10 / foot=yes on residential

>> Pedestrians can take the level footpaths/sidewalks instead taking the >> underpass: >> https://www.openstreetmap.org/way/6187386#map=18/50.94224/6.95277. >> There is no signage forbidding foot traffic. >>

Re: [Tagging] start_date variants

Sounds solid and already used quite a bit. But wait, is it start_date:somekey or somekey:start_date? Tobias On February 15, 2019 11:03:01 AM GMT+01:00, "Stephan Bösch-Plepelits" wrote: >Hi! > >I have some thoughts in the start_date tag, as I find it a bit too >vague - >meaning start of what?

Re: [Tagging] StreetComplete 10 / foot=yes on residential

irst place if the road is tagged as lit=yes? Asking for input. Tobias On February 15, 2019 1:59:25 AM GMT+01:00, Kevin Kenny wrote: >On Thu, Feb 14, 2019 at 7:26 PM Tobias Zwick >wrote: >> >> Is this now about the word "legal" or about the negation of the >quest

Re: [Tagging] StreetComplete 10 / foot=yes on residential

Is this now about the word "legal" or about the negation of the question? What difference does the latter make? Also, doesn't "probited" imply "legally" in common understanding? And of course, foot=no is tagged if a road is not accessible by foot. On February 15, 2019 12:52:16 AM GMT+01:00,

Re: [Tagging] StreetComplete 10 / foot=yes on residential

> Agreed. I don't see much of a difference between residential and higher > class roads. I would even argue that around here a sidewalk=no + foot=no > is even less likely on higher class roads than on residentials. How so? I have the impression, we (all) have different kinds of road in mind, when

Re: [Tagging] StreetComplete 10 / foot=yes on residential

The question asked is "Is this street accessible for pedestrians here?". It doesn't ask for the user's opinion on how safe it is. Also: https://lists.openstreetmap.org/pipermail/tagging/2019-February/042874.html On 14/02/2019 22:10, Volker Schmidt wrote: > I am sorry, this is not the correct

Re: [Tagging] StreetComplete 10 / foot=yes on residential

Wrede wrote: > Am 14.02.2019 um 20:50 schrieb Tobias Zwick: >> Alright, I will change it so that the question whether a road is >> accessible for pedestrians is never asked for residential roads (and >> living streets, service roads, pedestrians roads) for v10.1 >> > I

Re: [Tagging] StreetComplete 10 / foot=yes on residential

Alright, I will change it so that the question whether a road is accessible for pedestrians is never asked for residential roads (and living streets, service roads, pedestrians roads) for v10.1 Tobias On 14/02/2019 10:26, Florian Lohoff wrote: > > Hi, > i am seeing a growing number of

Re: [Tagging] StreetComplete 10 / foot=yes on residential

I agree that it would make sense to not ask whether a road has a sidewalk outside of built-up areas because in most cases, it will have no sidewalks. Regrettably, whether a road is in a built-up area or outside is not an information that is recorded in OSM. Tobias On 14/02/2019 18:23, Martin

Re: [Tagging] StreetComplete 10 / foot=yes on residential

This is, by the way, a bit of a different topic now, because the thread was originally about tagging foot=yes on residential, not whether foot=yes/no is limited to a *legal* access restriction. Anyway: I doubt access restrictions are used that way in reality. The absence of keys like the

Re: [Tagging] StreetComplete 10 / foot=yes on residential

apart from underpasses, bridges also intersections and similar constructs. They need not be trunk/motorroad. For example many road segments at Deichtorplatz and inner lanes of Willi-Brandt-Straße in Hamburg: https://www.openstreetmap.org/#map=18/53.54762/10.00345 On 14/02/2019 17:03, Philip

Re: [Tagging] StreetComplete 10 / foot=yes on residential

s where there is a sidewalk _and_ pedestrians a legally > required to use it, and use, obviously, foot=no for those cases where > there it is against the law to walk on the street (for roads where the > default is foot=yes) > > > On Thu, 14 Feb 2019 at 14:49, Tobias Zwick <mai

Re: [Tagging] StreetComplete 10 / foot=yes on residential

I don't take dismissive and generalizing statements on a project I have been putting 3+ years of lifeblood into, invest much of my free time in and offer as open source for the betterment of OSM, lightly. If you have a concrete constructive suggestion to make, do it, otherwise, save your breath.

Re: [Tagging] StreetComplete 10 / foot=yes on residential

think? Tobias On 14/02/2019 14:25, Tobias Zwick wrote: > Yes, there is a new quest in v10, which tags foot=yes/no. It is no > problem to make changes on it, but let me first provide some information > on it first, so we have a common basis to discuss: > > For any street that

Re: [Tagging] StreetComplete 10 / foot=yes on residential

Yes, there is a new quest in v10, which tags foot=yes/no. It is no problem to make changes on it, but let me first provide some information on it first, so we have a common basis to discuss: For any street that has been tagged as having no sidewalk, the StreetComplete asks the surveyor: "Is this

Re: [Tagging] The actual use of the level tag

I stumbled upon a real-world example yesterday that may make the attempt to have the level-tag describe a "global" order (as used in OpenLevelUp, JOSM etc.) somewhat impractical - with that level-selector UI element: So, Hamburg is a really flat city. And even still, the mall "Europa Passage"

[Tagging] weight limit in short tons

Hey there, as I was illustrating the https://wiki.openstreetmap.org/wiki/Key:maxweight article with some example signs and notes about pitfalls, I noticed that the wiki says here that the weight *must always* be defined in metric units. So, I also added a row in the examples table about the short

Re: [Tagging] The actual use of the level tag

On 22/01/2019 10:47, Lionel Giard wrote: > So, i'm really in favor of the level=* for a "data user friendly" tag > (that could correspond to local numbering, but not always) and a special > tag for the local levels. At this moment i would see a *local level tag > *like "level:ref=*" or

Re: [Tagging] The actual use of the level tag

On 21/01/2019 09:19, PanierAvide wrote: > Just for your information, there is also this "level:ref" tag which was > used in various context to solve this problem I know of "level:ref". However, on the SIT wiki page, "level:ref" is documented as a tag for the level-outline tagged with

Re: [Tagging] The actual use of the level tag

On 20/01/2019 23:39, Tobias Knerr wrote: > The main challenge I see with your proposal, though, is that the > levels=* tag on the building would be utterly required to make any sense > of the order of floors. Without it, applications would have no idea > whether "M" is above or below "P2", for

Re: [Tagging] The actual use of the level tag

>> - also the building with "ground_level=G" to define which level is >> the ground level. If ground_level is missing, 0 is assumed. >> > Do we really need a ground level? I think not. We need connections to > outside ways and entrances. Well, all of which I mentioned is optional. But I can

Re: [Tagging] The actual use of the level tag

> So from a SIT perspective, the problem isn't that the US (and other > places) call the ground level "1". It's that the level below that is > called "-1" rather than "0". You could still make it compatible with > Simple Indoor Tagging by adding a skipped_levels=0 tag to the building, > but this

Re: [Tagging] The actual use of the level tag

On 20/01/2019 18:06, Roland Olbricht wrote: > we have here in Wuppertal, Germany at least three indoor-tagged > structures that have street level entrances at multiple levels, making > "street level" a not-at-all defined concept. In case of the university > e.g. the main entrance is on level 7,

Re: [Tagging] The actual use of the level tag

it as mistake-prone as mapping a mall in the US. On 20/01/2019 16:16, Tobias Knerr wrote: > On 20.01.19 14:49, Tobias Zwick wrote: >> 2. generally, tagging definitions that are not intuitive to use (in a >> region) will not be used consistently (in that region), leading to >

[Tagging] The actual use of the level tag

Hi there, In the wiki, the level tag is defined to be a 0-based-index so that level=0 is the ground floor, i.e. at the street level. In other words, a two-storey mall with no basement will have shops at level=0 and level=1. This is intuitive for (at least) Europeans, people from Commonwealth

Re: [Tagging] Opening hours too long for OSM

Oh, you are right. I am sorry. So that opening hours tool understands more than what is defined in the specification. On 13/10/2018 12:35, Simon Poole wrote: > > > Am 13.10.2018 um 00:46 schrieb Tobias Zwick: >> It is already part of the specification that "Mo-

Re: [Tagging] Opening hours too long for OSM

ta entry faster > and less error prone and shorten the field all at the same time. > > Is this fit for a proposal? > > On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider wrote: >> >> On 10/11/18 11:47 PM, Jmapb wrote: >>> On 10/11/2018 5:21 PM, Tobias Z

Re: [Tagging] Opening hours too long for OSM

in openstreetmap-website, I opened a ticket to request this: https://github.com/openstreetmap/openstreetmap-website/issues/2025 On 11/10/2018 23:21, Tobias Zwick wrote: > Hey there! > > So, a user of StreetComplete came across the following complicated > opening hours for a shop (prettified):

Re: [Tagging] Opening hours too long for OSM

own months range. If you don't, that rule applies throughout the whole year. E.g. Jun: Mo-Sa 10:00-18:00; Sun 10:00-12:00 is interpreted as "open Mo-Sa 10-18 o'clock in June, always open on Sunday 10-12 o'clock". Tobias Am 11. Oktober 2018 23:47:06 MESZ schrieb Jmapb : >On 10/11

[Tagging] Opening hours too long for OSM

Hey there! So, a user of StreetComplete came across the following complicated opening hours for a shop (prettified): Jun-Sep: Mo-Sa 10:00-18:00; Jun-Sep: Su 10:00-12:00; Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Nov-Mar: Sa 10:00-12:00; Apr-May: Mo-Fr 10:00-12:30,15:00-18:00; Apr-May: Sa

Re: [Tagging] Arboretum - how to tag?

Well, an Arboretum is a "botanical tree garden", is it not? So why not leisure=garden (+ maybe additional tags, see wiki article)? On 10/10/2018 11:47, Warin wrote: > Hi > > I have an arboretum, Way: Arboretum (628753725), that is part of a > nature reserve and within a tree covered area. I

Re: [Tagging] Map a divide?

The definition in the wiki is a bit contradictory, in my opinion. On the one side, it states the thing about that the arrows should point away from the saddle point towards the peaks, like steps or a oneway street, on the other side it describes a ridge to connect several peaks and saddle

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

c in mind, not building=restaurant. Am 25. September 2018 02:54:02 MESZ schrieb John Willis : > > > >> On Sep 25, 2018, at 2:15 AM, Tobias Zwick wrote: >> >> I find it kind of unfitting to tag those as building=retail because >the >> kind of building is a

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

What about buildings like these though? (de: "Gasthof" / "Gaststätte" - "guest yard" = tavern / "guest place" = restaurant) https://noew.infomaxnet.de/data/imxplatformj/images/301_gasthof_fink_bad_erlach_1.jpg http://www.norbert-maas.com/foto/800_tetzelstein-8889.jpg

Re: [Tagging] JOSM error for a bus lane conditional

Looks fine to me. Perhaps open an issue in the JOSM bugtracker? On 23/09/2018 07:43, Warin wrote: > Hi, > > > There is a past entry of > > lanes:bus:conditional=1 @ (Mo-Fr 06:00-10:00,15:00-19:00) > > > That JOSM says is incorrect. There is a declared 2 lanes there on the way. > > What is

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

at "maxweight" is the best conditional name to denote "max gross weight". Tobias On 22/09/2018 23:52, Martin Koppenhoefer wrote: > > > sent from a phone > >> On 22. Sep 2018, at 23:48, Tobias Zwick wrote: >> >> What do you mean, what is the d

[Tagging] How to tag a building constructed for a gastronomic purposes?

Hey there Do you have suggestions what would be the appropriate building value for a building constructed for gastronomic purposes only, such as a restaurant/café/fast food/food courts etc? In context of Europe, I am thinking of: - inns/taverns (eating only) (de: "Gasthof"), for example in

  1   2   >