Re: [Tagging] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

Christoph Grenz via Tagging writes: > This tagging (a short section marked as oneway) is also quite usual in Germany > for this case, but restriction=no_entry is slowly becoming popular too. As usual, I think that in the short and medium term, tagging should be done with great consideration f

Re: [Tagging] Difference between "yes" and "designated" in access tags

Jass Kurn writes: > Need to point out for others reading this than I am in England, and > influenced by what I believe was likely the original intent of these tags, > that is mapping of the "English/Welsh, rights of way" > > I've always treated " foot|bicycle|horse=yes, as a means of showing I >

Re: [Tagging] traffic_signs: human readable values vs. ISO and law codes

yo paseopor writes: > Well, let's start. As you know there are values in traffic sign key that > are human readable and others that are the ISO code of the country plus the > code inside the traffic law of every country (from South Africa to USA). It > is not a big problem...except they are using

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

Minh Nguyen writes: >> It's a slippery slope, and pretty soon \pi is 3. > > Poor Indiana. ;-) The definition of the foot would apply to the ' and > ft abbreviations in every context, not just the ele=* key, so I'd > suggest considering it separately, probably without the formality of a > vote. Th

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

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 one-hundredths of an inch.  So I'm >> re

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

Minh Nguyen writes: > This proposal is using the ' symbol instead of the deprecated ft > symbol, but in practice almost every data consumer understands both > symbols equally. If someone feels strongly that ft would be less > error-prone, I'd encourage them to start a new proposal that would > af

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

As someone not happy about the deprecation of mailinglists, a few brief comments here: First, I think this proposal is fine, as documenting widespread practice. Regardless of my further comments, I think it's solidly progress to adopt it. While yonur comments about survey feet are valid,

Re: [Tagging] Postal verses locational addresses

Warin <61sundow...@gmail.com> writes: > On 12/9/23 03:57, Greg Troxel wrote: >> The fundamental issue is that there are postal addresses and what might >> be called "civil addresses" or "physical addresses" ('locational' I >> understand b

Re: [Tagging] Postal verses locational addresses

The fundamental issue is that there are postal addresses and what might be called "civil addresses" or "physical addresses" ('locational' I understand but is not normal English usage). In the US, we also have "911 dispatchable location" which is all about getting there physically and is US-bureauc

Re: [Tagging] Streets with gradually increasing widths

Kashish via Tagging writes: > Now I'm thinking of documenting two solutions on the wiki - > > 1. width:start=*/width:end=*, optionally with width=* for the minimum > width of the street, and with a word of warning about the results of > editors splitting ways. "optionally with width=* for the mi

Re: [Tagging] Streets with gradually increasing widths

Timothy Noname writes: > I've always thought actual measurements should be added to an individual > node and the minimum width should be on the way, splitting the way at > significant changes. This is an awesome suggestion. It allows recording as much data as anybody wants to measure, and doesn

Re: [Tagging] Streets with gradually increasing widths

BLUF: I strongly object to changing width= from minimum to average. Kashish via Tagging writes: > I recently purchased a laser distance meter, primarily for measuring > road widths so as to allow better routing for various vehicles. In the > process, I discovered that some roads can have a gra

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

Also, from a practical point of view, data points about cell service are not going to have any relationship to other items in the osm database. And, they are likely going to be semi-automatically collected, and people probably want contour lines that are generated from points, not the points. Ther

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

Minh Nguyen writes: > I for one support the drawing of hyperblobs. Thanks; I was pretty sure I was not alone. > If we look at our existing repertoire of shop=* values, it's pretty > clear that we aim for plain language when possible, although we do > sometimes fall short. > > shop=curtain, not

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

Mateusz Konieczny via Tagging writes: >> So I find the attention to legal definitions in the present discussion >> bizarre. >> > That is a different situation. > > shop=medical_cannabis would be analogous to shop=firearms > as it is a legal term (if I understood it right) with variety of differe

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

Martin Koppenhoefer writes: > sent from a phone > >> On 24 Jun 2023, at 00:29, Minh Nguyen wrote: >> >> But if we focus too pedantically on legal status at the expense of >> common sense, then we've reinvented designation=*, and mappers and >> data consumers have to find yet another key to expr

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

On June 23, 2023 1:50:58 PM UTC, Martin Koppenhoefer wrote: >Am Do., 22. Juni 2023 um 14:41 Uhr schrieb Greg Troxel : > >> >> Suppose in some other country, bakery is a term that means a shop that >> primarly sells sausages. We wouldn't say that this should be >

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

Martin Koppenhoefer writes: > sent from a phone > >> On 21 Jun 2023, at 15:52, Greg Troxel wrote: >> >> 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 &g

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

"Brian M. Sperlongano" writes: > On Thu, Jun 22, 2023, 8:08 AM Illia Marchenko > wrote: > >> But "freeway" is de facto equivalent of motorway, right? >> > > Freeway is a colloquial term that's only used in some parts of the country > and only signed as such in some states and often inconsistentl

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

Graeme Fitzpatrick writes: > On Tue, 20 Jun 2023 at 22:11, Greg Troxel wrote: > >> >> an air rifle is not a firearm, in English, because there is no >> combustion > > Unfortunately, in Australia at least, air rifles are actually officially > classed as fire

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

Marc_marc writes: > so now that we have a documented tag shop=knives, > how to tag a shop that sell knives and arcs ? shop=knives;arcs ? > of course not > when we have found the right term for this shop, the previous case > could have been handled in the same way with details in a secondary tag

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

Marc_marc writes: > 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 We have grocery and bakery.

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

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 - recreational shooters don't use weapons, the > mil

Re: [Tagging] [Voting] Level crossing train horn usage

Clay Smalley writes: > Voting has started on the proposal to introduce the key crossing:whistle=*. I find the "optional" to be strange. Regardless of a "whistles shall not be blown at this crossing", obviously an engineer can use the horn at any time if a danger exists. The bit about work crew

Re: [Tagging] road accident memorials

Anne-Karoline Distel writes: > I would like to be able to differentiate memorials for road traffic > accidents from other memorials along a road, because I'd really like to > know how many there are. Sometimes, it will be difficult to say without > local knowledge whether it was that or maybe if

Re: [Tagging] road accident memorials

Anne-Karoline Distel writes: > I would say that memorial:cause=traffic_accident would leave the options > open whether the victim intended to die or not. OK but IMHO traffic_crash is better. 'accident' is an assertion of no blame, and there are messy issues of bad luck and negligence. crash i

Re: [Tagging] Coach parking

Colin Smale writes: > UK native here... > > Looking at the vehicles, a bus would be more spartan, set up for fare > collection, doors for speedy un/loading etc whereas a coach would > almost always have only a single door (although some have more), be > more luxurious, be equipped with seat belts

Re: [Tagging] Coach parking

Anne-Karoline Distel writes: > [women's and parent's parking] I can believe it exists, and it being common in .eu explains why it's in the josm presets. > You're right about caravans/ RVs, that should be its own tag as well and > be rendered. For coaches, I'm in favour of amenity=coach_parking (

Re: [Tagging] Coach parking

Anne- Karoline Distel writes: > I came across a case where someone had added name=coach and name=car > to amenity=parking, which is obviously not how we do things [snip] I can't find it either. I remembered that JOSM presets have a lot more detail than the wiki. But I checked, and I don't see

Re: [Tagging] Tag government equals emergency defintion

> The places (stations etc) where the emergency response come from would > not be an 'office'; "An office is a place of business where > administrative or professional work is carried out. "  e.g. lawyers, > accountants, records, In the US we have the concept of "Emergency Management Agency" which

Re: [Tagging] Tagging type of ownership of a road

stevea writes: >> What is a point problem? > > Mmm, that IS a good question. Sorry, I meant that the proposal is a point solution, meaning one that applies to a very narrow view of the problem. Basically I meant what stevea just said. ___ Tagging mai

Re: [Tagging] Tagging type of ownership of a road

Jens Glad Balchen via Tagging writes: > I don't know how this works in other countries. The way it works here > is that the road owner contracts someone to do stuff, that is, to > actually go out and put down asphalt, cut vegetation, sweep debris, > clear snow, fix signage, etc. The road owner ca

Re: [Tagging] Tagging type of ownership of a road

Tod Fitch writes: > Greg mentions that in his part of the US the government doesn’t own > the land along the highway. I don’t believe that is true for most of > the US. The “right of way” includes a lot more land than just where > the pavement is located. It includes all land that had to be modif

Re: [Tagging] Tagging type of ownership of a road

Jens Glad Balchen via Tagging writes: > That does seem to capture it when used on roads. I see it's mostly > used for private roads. Is this tag use undisputed if used with > national/state/county/municipal? E.g. do people object to it being > redudant? You said you didn't like operator, and I s

Re: [Tagging] Combining "locked=yes" with various access tags

Mateusz Konieczny via Tagging writes: > Feb 25, 2023, 19:58 by g...@lexort.com: > >> I am assuming -- but the wiki is unclear -- that >> >> access=private, tagged on barrier=gate >> >> means that all modes of travel have a right of access only with >> permission >> > note that some may not phys

Re: [Tagging] Combining "locked=yes" with various access tags

Niels Elgaard Larsen writes: >>I don't see it that why. access=private, probably. access=destination >>means you can use a way if you decide to go someplace that you need to >>use the way to get to. But that's wrapped up with can you. > > If a way is access=destination, a router should only ta

Re: [Tagging] Combining "locked=yes" with various access tags

Niels Elgaard Larsen writes: > We have to accept that the tagging is never complete. And when > surveying, it is often easier to tag "locked" than "access" (we can se > the lock or try to open the gate but there are often no signs). So the > tagging might reflect that we know that a gate is usual

Re: [Tagging] dry swamps

Warin <61sundow...@gmail.com> writes: > In which case the OSM meaning of 'wetland' must change to incorporate dry as > well as wet. We need to adopt the professional definitions, not rewrite them roughly and not really correctly. Not sure which you are in favor of. >> Or if there are >> tree

Re: [Tagging] dry swamps

Andrew Davidson writes: > On 15/2/23 02:00, Greg Troxel wrote: >> For wetlands, the definitions in the US: >> >> https://www.fws.gov/media/classification-wetlands-and-deepwater-habitats-united-states >> > > Which is: > > In general terms, wetlands a

Re: [Tagging] dry swamps

Warin <61sundow...@gmail.com> writes: > The ‘dry swamp’ has no apparent way to tag it. These will not be found > in Europe, just as you don’t find deserts there. > > They have occasional water, not seasonal, not yearly but, say, between > 5 to 20 years they have water. As such they do not satisfy

Re: [Tagging] [Talk-us] New MapRoulette Challenge - Add Surface to Highways

"Brian M. Sperlongano" writes: > I am asking for TomTom to be straight with us and answer why they're so > gung ho about missing surface tagging on motorways. Despite the negative > reaction in the US, it seems that they're intent on spamming this nonsense > challenge worldwide, and they *refuse

Re: [Tagging] service vs. unclassified, conflicting definitions

Warin <61sundow...@gmail.com> writes: > I know of a road built for coal trucks by the coal firm tagged as > 'unclassified' yet it is a 'private road' not used by cyclist nor > pedestrians. The road standard is probably above that of > 'unclassified'. It runs from a coal mine to a power plant

Re: [Tagging] service vs. unclassified, conflicting definitions

Warin <61sundow...@gmail.com> writes: > On 1/10/22 20:25, stevea wrote: >> Makes sense to me, too, Greg. I don't know if it helps or hinders >> wider understanding, but I understand what Greg is saying here, and >> while his perspective is "Eastern USA" (and mine is "Western USA"), >> these don'

Re: [Tagging] Lyft and nameless sectioning in OSM

Warin <61sundow...@gmail.com> writes: > On 14/10/22 23:40, Greg Troxel wrote: >> Warin <61sundow...@gmail.com> writes: >> >>> On 13/10/22 02:42, Evan Carroll wrote: >>> In some places the local authorities have lots to do with landuse and >>>

Re: [Tagging] Lyft and nameless sectioning in OSM

Warin <61sundow...@gmail.com> writes: > On 13/10/22 02:42, Evan Carroll wrote: >>> There is such a thing as mixed use with our local authorities, >> residential+commercial. I wouldn't think residential and industrial >> mixes because of noise and pollution, at least in theory. >> Landuse has noth

Re: [Tagging] Lyft and nameless sectioning in OSM

Minh Nguyen writes: > 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)

Re: [Tagging] Lyft and nameless sectioning in OSM

Martin Koppenhoefer writes: > Am Mi., 12. Okt. 2022 um 16:25 Uhr schrieb Greg Troxel : > >> Part of the issue is that landuse should more or less follow property >> lines, unless there is some reason why not. > >> a several-acre parcel with >> a hous

Re: [Tagging] Lyft and nameless sectioning in OSM

Nick Santos writes: > I'd say if you think it's going to work, build it and show the community > examples of where it works well and where it doesn't. Discussing the > hypothetical makes us all revert to our own assumptions rather than looking > at a real comparison. I'm personally skeptical tha

Re: [Tagging] Lyft and nameless sectioning in OSM

Evan Carroll writes: >> Part of the issue is that landuse should more or less follow property >> lines, unless there is some reason why not. a several-acre parcel with >> a house and some trees is still landuse=residential on all of it, absent >> farming or some side industrial business. > > Pr

Re: [Tagging] Lyft and nameless sectioning in OSM

Evan Carroll writes: > *FOLLOW UP HYPOTHETICAL: * > I've been thinking about this a lot. I'm arguing here that, > > * Landuse for developed land can be better automatically generated when > there isn't a named polygon. > * If automatically generated, we can achieve perfect accuracy or quantify >

Re: [Tagging] Lyft and nameless sectioning in OSM

Andy Townsend writes: > I'd suggest asking them in the changeset about that edit, including > where they got the data from.  I'd also be perfectly reasonable to ask > them what the "proprietary sources" were that they used, Agreed. It would be more than reasonable to ask them about the propri

Re: [Tagging] Lyft and nameless sectioning in OSM

Martin Koppenhoefer writes: > Actually I do not believe “commercial zone” is a good description of > landuse=commercial because it implies zoning (prescription, also > planning i.e. permissible future landuse as opposed to de facto use of > land) and because it implies a certain scale. I think

Re: [Tagging] Lyft and nameless sectioning in OSM

You are using "zone" and that confuses me, because in the US zone is like zoning. Are we talking about landuse, or regulations for what land can be used for? I think it's reasonable to draw landuse=retail if it's actually true it's named and the boundary is more or less the property lines

Re: [Tagging] Better term for unisex

Zeke Farwell writes: > The proposal currently states: > >> Meaning of the unisex =yes >> is currently unclear: >> >>- gender neutral facility (as the "unisex" term in English); or >>- facility that accessible for men and women, either segre

Re: [Tagging] service vs. unclassified, conflicting definitions

stevea writes: > Ah, I thought of an exception: a service=alley is (usually, around > here, in California) a public way, but it IS more "service-" oriented, > like maybe it only gets used for rare, backyard-access by owners > (which would be exclusively private use), but maybe it DOES get used >

Re: [Tagging] service vs. unclassified, conflicting definitions

Kevin Broderick writes: > Another exception in New England, particularly, is that some states > (especially New Hampshire and Vermont) have a non-trivial number of > driveways that are privately maintained but in whole or part legally public > right of ways. In some cases, three public right of

Re: [Tagging] service vs. unclassified, conflicting definitions

"Shawn K. Quinn" writes: > Related to this, I've been tagging the driveways inside apartment > complexes as service, but a lot of mappers tag them as > residential. These roads are more similar to shopping mall driveways > than the type of road I would normally tag as residential; also note > th

Re: [Tagging] service vs. unclassified, conflicting definitions

Peter Elderson writes: > Unclassified, by definition, is a road on the traffic grid suitable > for motorised vehicles. It is not necessarily paved. Access > restrictions may apply, and usage may change in time, e.g the road > still connects, but is legally closed for cars except emergency > vehi

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

stevea writes: > We agree. The issues are both around the different behavior of the > (Carto) renderer when both landuse=residential and natural=wood are > combined (and there are highly complex ways they can be and are > "combined" in the OSM database), and around how mappers understand > these

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

stevea writes: > As I mentioned to Doug I exchanged a couple of emails with > user:jeisenberg (a principal contributor to Carto) about what was > going on with some examples of this, and Mr. Eisenberg explained to me > (in short) that it is a complicated ordering (or re-ordering) of > layers issu

Re: [Tagging] RFC ele:regional

On 2020-05-08 11:33, Martin Koppenhoefer wrote: It could be useful when mapping something like a building. You could establish a certain elevation as local zero (e.g. the elevation of the ground floor) and have all other levels based on this. It is something that could also not be needed becau

Re: [Tagging] RFC ele:regional

Martin Koppenhoefer writes: > I was not aware there weren't any meaningful differences (when comparing > some official height references to the German DHHN92 those in wikipedia.de > with delta information all are within 1m besides Belgium DNG/TAW, which is > -2.3). Thanks for looking into this.

Re: [Tagging] RFC ele:regional

Colin Smale writes: > As I mentioned before, the national datums of the Netherlands and > Belgium differ by over 2m, which for everything connected to water is > very significant. Waterways often form the border, with bridges that > cross the border. You cannot use a map/chart (at last for tidal

Re: [Tagging] RFC ele:regional

Martin Koppenhoefer writes: > Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel : > >> The notion of "local" has the same problem, and it is also a poor choice >> of words in that in surveying, "local", refers to coordinate systems >> established

Re: [Tagging] RFC ele:regional

Martin Koppenhoefer writes: > Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel : > >> 3) Look up the data sheet and mark it as ele:datum=NGVD29 or >> ele:datum=NAVD88 as it turns out. > > IIRR, in another mail, you wrote that the difference between these 2 is >

Re: [Tagging] RFC ele:regional

Peter Elderson writes: > Why not use a datum:value pair? > > ele=[datum:]value > > datum: is optional. If you don't know, just leave it out. Data users can > assume locally signed or known. Becuase, as I have said many times and no one seems to be listening, in OSM we have said that we use WGS84

Re: [Tagging] RFC ele:regional

Joseph Eisenberg writes: > Is there a reason to use this new tag ele:regional instead of ele:local=* > which is already mentioned on the Key:ele page? The notion of "ele:regional" is semantically wrong, because there is no way to map a particular lcoation to a single vertical datum. The notion

Re: [Tagging] RFC ele:regional

Mark Wagner writes: > What about regions where two or more reference systems are in common > use? If I copy an elevation from a USGS benchmark and put it in > "ele:regional", how does an end-user know if it's a recent benchmark > measured in NAVD 88 or an older benchmark measured in NVGD 29? Th

Re: [Tagging] RFC ele:regional

Simon Poole writes: > Am 04.05.2020 um 15:19 schrieb Kevin Kenny: >> Elevation as height-above-ellipsoid, unless you're using it in the >> intermediate results of a GPS calculation, is nonsensical. > > However if you read the argumentation on the Altitude page that was > exactly the reasoning: st

Re: [Tagging] RFC ele:regional

Martin Koppenhoefer writes: > So the question is how we can solve this. We could discourage the use of > the "naked ele" and encourage to always use a more specific subtag, e.g. But is there significant amounts of data that have ele as ellipsoidal height, more so than the prevalence of somewhat

Re: [Tagging] RFC ele:regional

Volker Schmidt writes: > I am not an expert, but it looks as if the Wiki page Key:ele > is not up-to-date. > I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid". > Hence there should be no difference between WGS84 and EGM96 elevations

Re: [Tagging] RFC ele:regional

Basically I think the whole elevation as height above ellipsoid is mostly a huge misunderstanding, and I wonder how much support there is for it. My memory matches what Martin pointed to: ele= is "height above sea level". And, given that layman's terms description, and that OSM is using WGS84, th

Re: [Tagging] RFC ele:regional

Following up to myself, a few things I didn't have time to say last night. Once we accept that the base notion of ele= means WGS84 geoid height (meaning the MSL sort of height), and that ellipsoidal heights basically have no place in OSM, then: 0) The entire notion of looking at a sign on a mou

Re: [Tagging] RFC ele:regional

Peter Elderson writes: > Thanks for explaining why my android phone says I am at +38m (+/- 3) in my > backyard when in fact it is at Dutch sea level -4.4m. Well, I didn't quite. The location API returns HAE.For a program to show that value to a human as "elevation" is buggy. So in additi

Re: [Tagging] RFC ele:regional

Martin Koppenhoefer writes: > I’m asking for comments on > https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional Two big comments: First, the current wiki documentation about ele and Altitude should be really straigthened out, so that we have a basis for what we are comparin

Re: [Tagging] highway=service, service=driveway vs highway=track

Mike Thompson writes: > I have always been under the impression that the highway tag should be > based off of function. Recently I have come across a number of cases > where driveways and residential roads were tagged "highway=track" > (perhaps because they are unpaved?), e.g. [0]. Before I cha

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

Martin Koppenhoefer writes: > apart from workshops, it is this overly broad meaning of "social facility" > that doesn't make the tag super useful. In the end you will have to add I agree with this overbroad notion. I am very much in favor of a top-level tag with subtags when all of the subthing

Re: [Tagging] insurance health

On 2020-04-14 21:16, Joseph Eisenberg wrote: OK, but are there any countries in the world where you can would normally buy health insurance in the same place as car or home or life insurance? I don't know. Many countries might not even allow this. If not, then this is a theoretical problem o

Re: [Tagging] insurance health

Agustin Rissoli writes: > In Argentina we want to correctly tagging offices of companies dedicated to > what we call prepaid medicine, by paying a monthly fee you access a series > of medical benefits. > We are hesitating between these tags: > > office=health_insurance > It has no wiki, it has 18

Re: [Tagging] building=public vs. building=civic

Martin Koppenhoefer writes: > While building=public seems defined, I have difficulties with building=civic, > which is according to the wiki public building appears to have its origin as a legal term, and I don't see it as a type of building at all. In the US the term might be "public accomoda

Re: [Tagging] Can highway=cycleway be limited to MTB?

brad writes: > How many trails are there that are not shared use? In my town, most of the town-owned conservation land has rules that say: trails shown on the official map may be used by hikers, bicycles and horses other trails may be used by hikers only So there are a lot that are not

Re: [Tagging] Can highway=cycleway be limited to MTB?

Snusmumriken writes: > On Thu, 2020-04-02 at 22:24 +1100, Andrew Harvey wrote: >> just usually only a certain kind of bicycle. > > Well, that's the problem, if one can't travel on a certain way with a > general purpose bicycle, then it shouldn't be tagged highway=cycleway I agree, and I think t

Re: [Tagging] Updating definition and description of place=square

Martin Koppenhoefer writes: > Frankly, I am not really familiar with the situation in North America > (besides some lessons about North American urbanism I have heard 20 > years ago). I am aware there are some developments that imitate 19th > century architecture, so even if many or most of the t

Re: [Tagging] Updating definition and description of place=square

Martin Koppenhoefer writes: > sent from a phone > >> On 29. Mar 2020, at 17:23, Greg Troxel wrote: >> >> Really it is a place=neighborhood >> with an indistinct boundary, even if there is a bit of eurosquare there. > > the fact there is a neighborhood which

Re: [Tagging] Updating definition and description of place=square

Paul Allen writes: > On Sun, 29 Mar 2020 at 00:55, Greg Troxel wrote: > >> Paul Allen writes: >> >> > I can think of one US city square which has "square" in the name >> > (not square shaped, though) that is rather well-known. If you >> &

Re: [Tagging] Updating definition and description of place=square

Joseph Eisenberg writes: > "taking "Harvard Square" as an example, > that refers to an area around the road junctions. It includes the > sidewalks, and it includes the businesses and buildings that are on the > roads that border the center, and even includes things that are perhaps > 50-100m dow

Re: [Tagging] Updating definition and description of place=square

Paul Allen writes: > I can think of one US city square which has "square" in the name > (not square shaped, though) that is rather well-known. If you > can't think of it the ball will drop eventually, at midnight on Dec 31st. But is that a place=square? That is simply an intersection which is

Re: [Tagging] Updating definition and description of place=square

Martin Koppenhoefer writes: > Am Di., 24. März 2020 um 18:23 Uhr schrieb Greg Troxel : > >> So one definition is >> >> a square is an area with an indistinct boundary that is known by a >> placename by most locals. > > I would rather say "distinct&q

Re: [Tagging] Updating definition and description of place=square

[kind of a joke about NY and New England; there is quite the rivalrly] What I take away from this exchange with you is that it is difficult to know what "square" means, and this it is unlikely that people will arrive at similar notions. Around here, squares are not square. (Oral tradition is tha

Re: [Tagging] Updating definition and description of place=square

Martin Koppenhoefer writes: > Am Mo., 23. März 2020 um 18:47 Uhr schrieb Greg Troxel : > >> We need it for en_US, too, because in the US, at least in New England, >> everybody knows what Square means and it is different from what this >> thread is discussing. > >

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

Tobias Wrede writes: > It seems I have a different understanding of the concept PO > box. Around here if you have a PO box mail is delivered there and you > go yourself pick it up, convenient for people who are rarely at home > or get huge amounts of mail. In more rural areas I have seen letter >

Re: [Tagging] Updating definition and description of place=square

Joseph Eisenberg writes: > That is why we need an actual definition of place=square that isn't > simply "a town square", because I need to be able to translate it into > Indonesia, for people who have never seen a European town square. I > suspect that Japanese and Korean will have the same probl

Re: [Tagging] Updating definition and description of place=square

I just looked at this discussion and am a bit baffled. We do have notions in OSM that tags mean what they are defined, not what the words might mean, but I think this situation is even more difficult. I live in New England, and we have lots of place names "Foo Square". Perhaps the biggest is "Har

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

Joseph Eisenberg writes: > I agree with "addr:mail=*" as a tag to add to guesthouses, shops, > farms and other businesses, as a way to send letters and perhaps small > parcels, which might be delivered to a PO Box or some rural delivery > system, rather than to the physical address of the shop, b

Re: [Tagging] Barbecue disposal bins

Graeme Fitzpatrick writes: > Is anyone as irritated as I am by the shortening to 'bbq'. > > Sorry, no - it's a standard term, at least around here! :-) I am irritated by the misuse of barbecue to refer to large class of anything to do with a grill. Barbecue properly refers to cooking at low hea

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

"ITineris OSM" writes: > I need help in tagging a special kind of survey points: geodesic towers. Are they called "geodetic" towers? > These are tubular concrete structures, with usual steel triangulation tripods > on their top. Wow, those are pretty big! > They have the precise benchmark on

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

Anne-Karoline Distel writes: > I've been surveying benchmarks for the past four months and I would like I'm glad to hear that. > to propose an alternative to benchmark=yes for survey points: > https://wiki.openstreetmap.org/wiki/Proposed_features/survey_point:benchmark > The reason being that I

Re: [Tagging] amenity=faculty?

Mateusz Konieczny via Tagging writes: > Universities may have faculties, that often deserved to be mapped separately. > > For example university may take a large area, possibly disjointed area across > the city > but Faculty of dentistry, Faculty of forestry, Faculty of mathematics etc may > be

Re: [Tagging] Disputed territory mapped as a country

Martin Koppenhoefer writes: > Mateusz, offlist deliberately. While we're at it, could the list admins fix the BROKEN REPLY-TO? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

Jmapb writes: > Hi all, just noticed this passage on the cycleway=* wiki page ( > https://wiki.openstreetmap.org/wiki/Key:cycleway ): > >> For mapping a separate path (on a separate way) dedicated to cycling >> traffic use highway=cycleway. Foot traffic is restricted on these paths. >> >>   *  Do

  1   2   3   4   >