Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

Vào lúc 04:08 2024-01-28, Greg Troxel đã viết: Minh Nguyen writes: Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven

Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết: Uh so I did the math, and unless I've got this wrong, the difference between survey feet and international feet for tagging, let's say, Mount Everest, is less than seven one-hundredths of an inch.  So I'm really not even sure why we're

Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

Vào lúc 16:01 2024-01-27, Greg Troxel đã viết: I would expect the proposal to give an example. It seems that one would have a tag ele=6288 ft for Mount Washington (showing my East Coast bias). Thanks, I added this to the existing examples [1], though the summit sign unusually

[Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

This is a second request for comments about documenting the option to express an elevation in feet within the ele=* key. Here is the full proposal: The first RFC took place in December 2021 [1], but I put the proposal on hold for

Re: [Tagging] [Talk-GB] Fords and how to provide information to help with routing apps

Vào lúc 01:00 2023-07-05, Warin đã viết: Many 'fords' in Australia are normally dry. When the river runs high those fords can become impassable for quite some time .. weeks.. Those who travel there know this, those that don't .. well the Police normally place 'Road Closed' signs out. This

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

Vào lúc 01:47 2023-06-27, Martin Koppenhoefer đã viết: On 26 Jun 2023, at 20:50, Minh Nguyen wrote: For what it's worth, the Sporting Goods Retailers subindustry in NAICS includes "gun shops". what’s the category for multi role combat aircraft or heavy battletanks? Aircraft

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

Vào lúc 05:14 2023-06-26, Greg Troxel đã viết: Mateusz Konieczny via Tagging writes: and therefore a poor terms to use in OSM (like shop=firearms apparently) "Firearm" is first a technical term, and secondarily (and relatively recently) a legal one. The reason that's not a good word to use

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

Vào lúc 10:23 2023-06-22, Mateusz Konieczny via Tagging đã viết: Jun 21, 2023, 15:51 by g...@lexort.com: It is absolutely the wrong thing to say that shop=firearms means "a shop that sells whatever the local law means by firearms". This is a general principle in OSM that we define

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

Vào lúc 06:47 2023-06-23, Martin Koppenhoefer đã viết: I believe the US is an exception then, at least the current wiki confirms what I wrote (and in this case I didn't write it myself ;-) ) , from highway=motorway: Typically highway =motorway

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

Vào lúc 10:44 2023-06-19, Marc_marc đã viết: Does it make sense to create a primary tag for each type of weapon? I find it very fragmenting, especially as there will inevitably be shops selling 2 items with different primary tags, which merits a secondary tag and not a shop=guns;knives I'm

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

Vào lúc 16:26 2023-06-19, Greg Troxel đã viết: Graeme Fitzpatrick writes: As possible solution, *shop=weapon* Sorry, but speaking as a recreational shooter, & on behalf of all others, we find the use of the term "weapons" for our chosen sporting tools more than somewhat offensive -

Re: [Tagging] navigational aid relation

Vào lúc 02:56 2023-06-18, Martin Koppenhoefer đã viết: Am Sa., 17. Juni 2023 um 21:48 Uhr schrieb Minh Nguyen <mailto:m...@nguyen.cincinnati.oh.us>>: Here in the U.S., the meaning of an address depends on who's using it. To the tax authorities, it refers to the who

Re: [Tagging] navigational aid relation

Vào lúc 21:59 2023-06-16, Volker Schmidt đã viết: When trying to reach a destination that is defined by a complete address (city, street name, house number or name) is that the last meters of the route are, potentially,  much different for a

Re: [Tagging] navigational aid relation

Vào lúc 11:48 2023-06-15, Sarah Hoffmann via Tagging đã viết: On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote: I neglected to mention another common heuristic: the geocoder can automatically bias the address point toward the street named in addr:street when coming up

Re: [Tagging] navigational aid relation

Vào lúc 08:29 2023-06-15, Sebastian Gürtler đã viết: You only would have to change the wiki page Key:entrance and encourage people to allow single nodes with the tag entrance=yes and addr:xyz (like this: https://www.openstreetmap.org/node/10979019687) if it is not obvious where the entrance to

Re: [Tagging] navigational aid relation

Vào lúc 00:26 2023-06-14, Florian Lohoff đã viết: Management Summary: In navigation/routing the point the router is routing to is the nearest point on the routable network from the poi/address we like to navigate to. The nearest point may not be a location where the address/poi can be

Re: [Tagging] date not in YYYY-MM.DD format should go into a sufix edtf ?

Vào lúc 14:56 2023-05-29, Marc_marc đã viết: a contributor change to wiki to tell that "For dates that cannot be expressed in -MM-DD format, such as approximate or uncertain dates, or times of day, use the end_date:edtf=* key in addition to this key. " did you agree with that ? start_date

Re: [Tagging] Route names being applied to tracks/paths

Vào lúc 08:54 2022-12-30, Jmapb đã viết: On 12/30/2022 2:22 AM, stevea wrote: I agree with Mateusz here:  whether to tag a way after the name of a route which includes it (if it didn't have a name=* tag beforehand) isn't a "one size fits all" situation.  It's difficult to describe what the

Re: [Tagging] Foot / sidewalk access tagging

Vào lúc 17:29 2022-12-18, Zeke Farwell đã viết: On Sun, Dec 18, 2022 at 6:33 PM Minh Nguyen <mailto:m...@nguyen.cincinnati.oh.us>> wrote: Vào lúc 15:00 2022-12-18, Zeke Farwell đã viết: > I'll try to answer the original question as succinctly as possible.  As &g

Re: [Tagging] Foot / sidewalk access tagging

Vào lúc 15:00 2022-12-18, Zeke Farwell đã viết: I'll try to answer the original question as succinctly as possible.  As I understand it, the combination foot=no + sidewalk=separate means walking is not allowed at all on this street and the sidewalk belonging to this street is mapped as a

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

Vào lúc 07:54 2022-12-02, Tobias Knerr đã viết: On 02.12.22 15:02 Mateusz Konieczny wrote: If it is second case of preprocessing being impossible - why do massive duplication and ask to duplicate ref value AND name value AND highway value? The duplication-free solution of referencing the

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết: I have good news! There is preprocessing solution for large (nearly all?) simple cases, written in Kotlin and is a part of StreetComplete. StreetComplete would be able to handle cases listed in its sidewalk detection (used to

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 02:08 2022-12-01, Volker Schmidt đã viết: This proposal is incorrectly giving the impression that it is in the spirit of the crossing:markings tag. This tag was meant to complement and refine the existing tagging of crossings in some cases, but certainly not to replace, wholesale the

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 23:01 2022-11-28, Martin Koppenhoefer đã viết: On 29 Nov 2022, at 00:52, Minh Nguyen wrote: Even if it weren't for iD's long-gone preset, I don't think an ostensibly global tag should be defined based on the narrow provisions of a specific country's laws. I don’t think

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 15:18 2022-11-28, Martin Koppenhoefer đã viết: crossing:markings is just about this, road markings, and while crossing_ref=zebra wasn’t documented for a long time, people that added it around here told me it was about the presence of road markings as well. Crossing=zebra is about a

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

Vào lúc 04:55 2022-11-28, Martin Koppenhoefer đã viết: Just because there is a now a way to map crossing markings separate from other properties, does not imply all the tagging we have is not needed any more, rather I would see "crossing:markings" as implicit, for example on a

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

Vào lúc 10:44 2022-11-23, Zeke Farwell đã viết: A 100+ message thread on the mailing list is no better than on Discourse.  The problem is people spending too much time writing many long messages, and not enough time reading and thinking.  Much as I would love if everyone could learn to write

Re: [Tagging] species:language to loc_name:language

Vào lúc 08:22 2022-11-21, Carlos Sánchez đã viết: In a lot of cases, users are using local names in the values for species and genus keys. This is an error as genus and species only exist in latin. For local/vulgar name users should use another key or be obtained using the wikidata

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

Vào lúc 22:07 2022-11-19, Graeme Fitzpatrick đã viết: On Sun, 20 Nov 2022 at 15:38, Minh Nguyen <mailto:m...@nguyen.cincinnati.oh.us>> wrote: There are some ways to draw attention to a wiki talk page comment in general. For example, if I add {{ping|Fizzie41}} to my commen

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

Vào lúc 18:17 2022-11-19, Graeme Fitzpatrick đã viết: I do have some concerns about the talk pages though. Over time, I've asked quite a few questions on various talk pages, seeking clarification of tag details, or whether this tag would apply in these circumstances etc. I doubt as many as

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

Vào lúc 17:24 2022-11-19, Matija Nalis đã viết: On Sat, 19 Nov 2022 12:12:22 +0100 (CET), Cartographer10 via Tagging wrote: This proposal makes sure there are 2 required platforms where people have to announce it. That way people have the choice to follow one of the two channels of their

Re: [Tagging] care services

Vào lúc 04:12 2022-11-19, Georges Dutreix via Tagging đã viết: My question is for a unique company providing different services for assistance at home, but the goal is not healthcare. Probably office=home_aide could be good, I am questionning english native speakers for the right word. In

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

Vào lúc 17:39 2022-11-18, Matija Nalis đã viết: That way, maximum reach will be accomplished, and all "people could decide for themselves where they wish to communicate". So instead of say 30 messages on tagging mailing list for some proposal, we can have 5 messages on tagging ML, 2 on

Re: [Tagging] care services

Vào lúc 10:51 2022-11-17, Philip Barnes đã viết: On Thu, 2022-11-17 at 19:21 +0100, Georges Dutreix wrote: Le 17/11/2022 à 18:52, Philip Barnes a écrit : I have used office=home_care for a care company. I found as well amenity=personal_service used 110 times Would be "amenity" better than

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

Vào lúc 14:51 2022-11-13, Brian M. Sperlongano đã viết: You're using the wrong metric.  The standard for a proposal, which purports to change tagging standards that affect *the entire community*, should be to advertise it as widely as possible.  With the new forums picking up interest and

Re: [Tagging] amentiy=donation_centre?

Vào lúc 19:02 2022-11-12, Graeme Fitzpatrick đã viết: On Sun, 13 Nov 2022 at 10:37, António Madeira > wrote: I don't know of any charity which buys items to then resell or distribute them, although that can happen in some obscure situation. There's

Re: [Tagging] amentiy=donation_centre?

Vào lúc 12:06 2022-11-12, António Madeira đã viết: There's office=charity and shop=charity. I think the second one corresponds to what you're looking for. Maybe, but only if there's some tag to clarify that the shop=charity only accepts items as opposed to selling them. Apparently we avoided

Re: [Tagging] amentiy=donation_centre?

Vào lúc 11:26 2022-11-12, Timothy Noname đã viết: I think people already use Amenity=recycling Recycling_type=container or centre And then specify whether it takes clothes and shoes etc Recycling:clothes=yes Long ago, I helped to promote this overloading of amenity=recycling in the U.S. At

Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1 - General comment

Vào lúc 04:43 2022-11-06, bkil đã viết: That's an interesting problem. Does the mediawiki API support CORS? If yes, we could easily create a very simple third party GUI form for it just for voting or adding a new comment on the talk page. In addition to the osm-proposals site, Martin is

Re: [Tagging] Proposal process [was: healthcare]

Vào lúc 03:26 2022-11-06, m...@marcos-martinez.net đã viết: Some time ago I asked Alexander Borsuk (Organic Maps). The context was the debate on the "contact" controversy but it can be extended to other less heated topics... (The conversation was in the open OM Telegram channel and can be

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

Vào lúc 00:23 2022-11-06, easbar.m...@posteo.net đã viết: Ok, sure, as far as I am concerned it doesn't have to be `unrestricted` and could just as well be `none` or `no`. But at least there seems to be consensus that a) The `except` tag could/should be replaced with such a

Re: [Tagging] Feature Proposal - Voting - historic

Vào lúc 18:16 2022-11-04, Martin Koppenhoefer đã viết: On 4 Nov 2022, at 13:17, Marc_marc wrote: our "sister" project (wikipedia) has no problem defining what is an anecdote and what is "relevance from a historic viewpoint", I don't see why we should have any issue doing it. Mappers are

Re: [Tagging] Feature Proposal - Voting - historic

Vào lúc 09:36 2022-11-04, Anne-Karoline Distel đã viết: The point I was trying to make is that in the iD editor, the field "inscription" comes up as a default and is mis-used for descriptions. I would like to see a way to prevent that. Obviously, a signpost has an inscription, but that field

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

Vào lúc 00:02 2022-11-01, easbar.m...@posteo.net đã viết: Thanks, Minh. Yes, there is no way to indicate an order of precedence between relations. But I also do not understand yet why this should be needed. It would be sufficient to have one relation per 'turn', i.e. for any combination of

Re: [Tagging] Using restriction and restriction:vehicle for the same restriction relation should be discouraged

Vào lúc 01:07 2022-10-29, Tobias Knerr đã viết: On 29.10.22 07:13 easbar.m...@posteo.net wrote: I like your idea of not using the except tag but rather something like restriction:value=unrestricted. Actually that would be the first useful combination of restriction and restriction:vehicle that

Re: [Tagging] Tagging of community mailboxes (cluster maiboxes)

Vào lúc 02:28 2022-10-23, Martin Koppenhoefer đã viết: sent from a phone On 23 Oct 2022, at 02:03, wolfy1339 via Tagging wrote: Here's a picture for reference, https://upload.wikimedia.org/wikipedia/commons/0/0d/CanadaPostCommunityMailboxes15.jpg for this kind, informal=yes should not

Re: [Tagging] Feature Proposal - Approved - migration to use belarusian as default language in Belarus for tagging

Vào lúc 21:56 2022-10-15, bkil đã viết: Why did I get a private message about this? I think they've been reaching out to everyone who's edited any of the relevant keys (name, destination, etc.) in Belarus to make sure there are no surprises. They must've cast a very thorough net. --

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 05:45 2022-10-15, Greg Troxel đã viết: Warin <61sundow...@gmail.com> writes: OSM does not map illegal activity. Taken to the extreme, perhaps, but we are talking about things that are done in the open and clearly visible to all. Landuse, by its nature, occurs on timescales of

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 01:45 2022-10-13, Martin Koppenhoefer đã viết: Often names refer to the whole part of the settlement, but there are also named contiguos, single use developments where adding the name to the landuse seems to "work" (not generally, only in some instances). The latter is especially

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 10:56 2022-10-12, Evan Carroll đã viết: But in some places, mappers have been more rigorous about respecting each building's architectural origins. This is all 100% new to me.  Where is it documented that a "shop" in a detached house should be mapped as a detached house,

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 09:12 2022-10-12, Evan Carroll đã viết: if you have x number of detached residences occupied by offices, it is not a landuse=residential Then it's mistakenly tagged. You do not use `building=detached` for shops and offices. Per the wiki,

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 07:58 2022-10-12, Marc_marc đã viết: Le 11.10.22 à 20:48, Andy Townsend a écrit : That was added in https://www.openstreetmap.org/changeset/127101982 , I am surprised that no one is concerned about the compatibility between its proprietary source and osm Lyft's policy lead has

Re: [Tagging] Feature Proposal - RFC - Historic

Vào lúc 07:16 2022-10-12, Marc_marc đã viết: approving that "historic=* is about "with historical significance" doesn't change anything about already existing historic=value without historical significance. existing tags always remain unless someone has the courage to try to make progress on the

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 18:27 2022-10-11, Shawn K. Quinn đã viết: If, like me, you want to see fewer unnamed landuse areas in your backyard, map more named landuse areas corresponding to retail and residential developments. These areas not only reduce the pressure to "fill in" the map visually but also add

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 14:06 2022-10-11, Evan Carroll đã viết: This is also really well said, and we should not overlook that I'm new to OSM and don't know of the time when buildings were not mapped. I see all buildings mapped, and wonder why I need a container to tell me that all things in it are that which

Re: [Tagging] RFC - More sensible values for fountain=*

Vào lúc 01:22 2022-10-11, Marc_marc đã viết: the namespace isn't needed, it's just a bad pratice due to a missing feature in iD (another editor uses taginfo combinations to propose the most relevant values, iD on the other hand proposes everything often without filter, but as I said, it is not

Re: [Tagging] RFC - A broad look at fountains

Vào lúc 03:08 2022-10-09, Peter Neale via Tagging đã viết: A tap is a device to control the flow of whatever liquid (or gas, I suppose) is coming out.  Potable water, non-potable water; lemonade; petrol (gasoline), Oxygen, whatever... I think you're joking about the lemonade, but here's

Re: [Tagging] RFC - A broad look at fountains

Vào lúc 23:50 2022-10-08, stevea đã viết: On Oct 8, 2022, at 11:44 PM, Graeme Fitzpatrick wrote: On Sun, 9 Oct 2022 at 16:36, stevea wrote: Disagree, some are are the same feature .. taps can be drinking water .. or 'not suitable for drinking' (legal CYA?), 'recommend you boil' (more

Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

Vào lúc 04:22 2022-10-08, ael via Tagging đã viết: On Sat, Oct 08, 2022 at 09:52:46AM +0200, Martin Koppenhoefer wrote: sent from a phone On 8 Oct 2022, at 07:55, Warin <61sundow...@gmail.com> wrote: Example Tom Bass Wall Fountain, Sydney, Australia 1963. Nicknamed "The Urinal" for obvious

Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

Vào lúc 03:04 2022-10-05, Warin đã viết: On 5/10/22 08:25, Minh Nguyen wrote: Vào lúc 11:54 2022-10-04, Jass Kurn đã viết: I've just noticed there is a bubbler tag being promoted? Which appears to be an American English term for a British English drinking fountain. Why promote another term

Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

Vào lúc 11:54 2022-10-04, Jass Kurn đã viết: I've just noticed there is a bubbler tag being promoted? Which appears to be an American English term for a British English drinking fountain. Why promote another term, and use an American English term. What was wrong with calling a drinking

Re: [Tagging] Terminology primary feature, main tag, etc..

Vào lúc 10:36 2022-10-02, martianfreeloader đã viết: Hi, I'm unsure if I'm using correct terminology. I have come across these terms in the OSM ecosystem: - primary feature [1] - main key [2] - primary key [3] - feature tag [4] 1) Are these synonyms (except for the key/tag distinction)? 2)

Re: [Tagging] Feature Proposal - RFC - Require proposal announcements to be made on the new forum instead of the mailing list

Vào lúc 11:04 2022-09-24, Mateusz Konieczny via Tagging đã viết: My question was about getting notifications of new topics - to avoid missing RFC/vote. By the way, the wiki also has tools for keeping track of RfCs and votes under way. For example, you can track recent changes to any proposal

Re: [Tagging] Tagging sewage treatment basins

Vào lúc 09:42 2020-12-18, Martin Koppenhoefer đã viết: Am Fr., 18. Dez. 2020 um 12:32 Uhr schrieb Paul Allen >: I'm not entirely happy with natural=water being applied to either sewage treatment or slurry.  Neither are natural and neither store water.

Re: [Tagging] Mapping bicycle-only turn lanes

Vào lúc 14:08 2020-12-08, Mateusz Konieczny via Tagging đã viết: Mapper in Poland run into a tricky case and asked for help. I am forwarding this a bit weird case. Photo is at https://commons.wikimedia.org/wiki/File:Krak%C3%B3w_Brodzi%C5%84skiego_(5).jpg

Re: [Tagging] Animal trails

Vào lúc 16:32 2020-11-30, Warin đã viết: I would not encourage the use of the tag 'animal' as it is a real mess! See taginfo for the variety of values that have no coordination. Example animal=wellness ... for which animals and then the problem of tagging that... terrible. animal=wellness is

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

Vào lúc 06:17 2020-11-19, Tobias Zwick đã viết: 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

Re: [Tagging] Meaning of "administrative" in boundary=administrative, in your country?

Vào lúc 14:27 2020-05-13, Joseph Eisenberg đã viết: At the US talk mailing list and https://wiki.openstreetmap.org/wiki/Talk:United_States_admin_level there has been discussion about whether or not certain features should be

[Tagging] Automated check cashing machines

In the United States, there's a network of automated check cashing machines called SAM. The machines are usually found inside grocery stores and look like ATMs. Unlike conventional ATMs, they have no access to the banking network: they accept checks (or traveler's checks or money orders) and

Re: [Tagging] Fuel octane ratings: RON versus AKI

On 2019-07-19 17:24, Minh Nguyen wrote: Compounding the matter, for several years, the fuel:* wiki page has specified that octane ratings must be expressed in RON, which is used in more countries. [3] In a few countries including U.S., octane ratings are only posted in RON, not AKI

[Tagging] Fuel octane ratings: RON versus AKI

This week's weeklyOSM [1] included a suggestion to minimize the number of fuel:* subkeys, which reminded me that the fuel tagging situation in the United States is actually quite complicated. The same generic grade of gasoline ("regular", "mid-grade", "premium") may have a different octane

Re: [Tagging] Maxweight wiki page changes

On 2019-07-06 04:49, Colin Smale wrote: It is an intrinsic danger of international projects that words mean different things to different people. Hence the importance of keeping things objective, and recording facts, rather than judgements. It's about what things ARE, not what they are CALLED.

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

On 2019-07-06 06:17, Joseph Eisenberg wrote: In May, yumean1119 suggested tagging Japanese "cram schools" as either office=educational_institution + education = cram_school or amenity=prep_school And then iD and the name_suggestion_index started using amenity=prep_school I added some test

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

On 2019-01-20 05:49, Tobias Zwick wrote: 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

Re: [Tagging] weight limit in short tons

On 2019-01-26 15:27, Warin wrote: The only problem is the 'ton'. I n the USA 2,000 pounds In the UK 2,240 pounds. Resolving this? units 'ton us' and 'ton uk' ??? I've been converting to pounds (lbs), which avoids this ambiguity with precise conversions. Apparently I'm not alone. [1] But

[Tagging] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

Recently, iD was changed so that shop=chemist is labeled as "Drugstore" for American English users (and continues to be labeled "Chemist" for British English users). [1] An American mapping a Walgreens, CVS, or Rite Aid who searches for "drugs" will see the following choices, in order: *