[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 a

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 semanti

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 like

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 Ma

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 a

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] 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 ac

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 garag

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

[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 with

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 with

[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] 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 t

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 si

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 a

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 OS

[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. Loo

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

still legally 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:

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?

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 mar

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 s

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

a visualization (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

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

[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 orch

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 add

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 th

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

Re: [Tagging] How to tag pedestrian lanes?

ht/left/both, >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

[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 co

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] 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 coun

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 >>

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, and

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 ta

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 come

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 exam

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 "indoor=leve

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 "loc_level=*

[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

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" ...

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] StreetComplete 10 / foot=yes on residential

hat do you 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 stree

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

those cases 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 Zwic

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 Barne

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 mentione

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 Kop

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 changesets

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

obias 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 >> &

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 appr

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

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, Jos

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

n the first 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

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

>> 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. >> (https://www.google.de/maps/@50.978,6.9530483,3a,60y,190.35h,87.27t/data=!3m6!1e1!3m4!1

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 tu

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] 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 (doesn't

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 t

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 superced

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 can

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 by

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 mph

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] 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

"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 b

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 Tob

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 inst

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 be

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

id OpenSource Software Repository) 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 scatter

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] 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 a

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 non

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 shop=cannabis

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 not

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 o

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 w

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] 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 als

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), a

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

Tobias 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 u

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 Taggin

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 ther

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 bot

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 GMT+02:

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 (the

[Tagging] Dashed/Soft Cycle Lanes

Hello I am trying to achieve an agreement on an extension of the cycleway tagging scheme. Specifically on how to tag cycle lanes with dashed road markings. I opened a topic in the forum for this a few days ago and would like to make you aware of it: https://forum.openstreetmap.org/viewtopic.php?

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

The tagging as you described is correct. An alternative is to use simply cycleway=lane or cycleway:left=lane cycleway:right=lane if you want to be explicit about that there are lanes on both sides of the street. I venture to say that any data consumer that processes bicycle-data will ass

[Tagging] Tagging shared zones?

Hello, Should ... shared zones (AU, NZ), also known as... - Begegnungszone (CH, AT)[1] - Zone de rencontre (BE, FR)[2] - Zona de coexistência (PT) ... be tagged specifically in OpenStreetMap? And if yes, with what? Shared zones are similar to living streets, in that they are both implementations

Re: [Tagging] Tagging shared zones?

gt; sometimes these also match highway=service (service=alley) so it can be > hard to decide which tag to use... > > Either way I tag them with maxspeed=10 (lower speed limit), > foot=designated, bicycle=designated, motor_vehicle=designated since > that's what the signage indica

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

Interesting. But I do think that this person is right. My research so far showed that neither source:maxspeed nor maxspeed:type nor any of the other variants sufficiently cover the topic of default speed limits (see last paragraphs). So, it makes little sense to migrate to a solution that is perha

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

olen%C3%A9_rychlosti_(2016_-_verze_2015-07-31).jpg [2] see for example https://en.wikipedia.org/wiki/30_km/h_zone On 18/09/2018 01:07, Paul Johnson wrote: > On Mon, Sep 17, 2018 at 4:42 PM Tobias Zwick <mailto:o...@westnordost.de>> wrote: > > In order to find an optimal and

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

10:41 AM, Tobias Zwick wrote: >> >> There is a misunderstanding. >> >> So, there are 597 towns, 77 counties and 2 councils in the state of >> Oklahoma and I understand that you want to say that all these entities >> have authority over defining the default speed limit

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

> (Incidentally, I think 7 of the 8 Australian states & territories have > the same limits?) Almost. Western Australia and Northern Territory has 110 km/h, Tasmania 100 km/h only on concrete or asphalt surface and 80 km/h otherwise; Northern Territory furthermore sets the speed limit within built-

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

it. On 19/09/2018 07:15, Mark Wagner wrote: > On Tue, 18 Sep 2018 20:36:06 +0200 > Tobias Zwick wrote: > >> From your anecdote, it seems, an implicit speed limit tagging scheme >> is even more important in the US than for example in the UK > > In my part of the US, a

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

This is an interesting idea (inspired by the ongoing discussion about mapping language borders?), but unfortunately it wouldn't work. Sorry for linking to this all the time but it is really necessary in order to understand the big picture: https://wiki.openstreetmap.org/wiki/Default_speed_limits

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

This is a good argument against tagging an explicit maxspeed=X when there is actually no speed limit sign around (X is what the OSM mapper by his knowledge about the law thinks should be the default limit here). Unfortunately, this is still common practice because of the lack of a scheme for taggi

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

Okay, so US-American legislation usually differs between "residential district" and "business district" for maxspeed defaults, as opposed to "built-up area" in most other countries. Actually, there is a tag to denote that a street is in a residential district or business district. It comes from th

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

uilt_up > > > djakk > > > Le mer. 19 sept. 2018 à 21:27, Tobias Zwick <mailto:o...@westnordost.de>> a écrit : > > Okay, so US-American legislation usually differs between "residential > district" and "business district" for maxspe

  1   2   >