On Sat, Apr 27, 2024 at 9:01 PM Fernando Trebien
wrote:
> "a road of highest importance, forming the main road network there,
> should be highway=trunk" [1]
> "highway=trunk: The most important roads in a country's system that
> aren't motorways." [2]
>
> The comments here suggest that for a
On Thu, Apr 25, 2024 at 10:13 AM Christoph Hormann wrote:
> [...] you can try to record semantically meaningful information about the
> geographic reality.
>
> [...] Even more clear in that regard is the use of secondary tags like
> snowmobile=yes, ice_road=yes, surface=ice.
I don't think
I'm sure the answer to this question... CRITICAL ... to many data
consumers...
Anyways:
This:
https://www.openstreetmap.org/way/1159748452
seems fine, if you can convince me that it's actually a road. Clearly the
most significant road in the area...
It's essentially the only road *grin*
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 discussing it beyond the fact that we're all nerds
about this
On Thu, Aug 10, 2023, 6:28 AM Marc_marc wrote:
> with this argument, you'd have to remove all the shop= office=* craft=*,
>
Nonsense. Everyone knows what a craft=brewery is. It's not volatile at
all. They either make beer or they don't. Cell reception is ephemeral.
> let's also remove
No, this does not fix it. The fundamental thing that you're trying to map
here simply doesn't belong in OSM, the proposal will not pass, and I would
advise you to stop wasting your time and everyone else's on it.
OpenStreetMap is a database of verifiable facts, not scientific
measurements, and
This isn't really appropriate data for OSM, sorry.
On Sun, Aug 6, 2023, 3:21 PM NickKatchur via Tagging <
tagging@openstreetmap.org> wrote:
> Hello,
>
>
> I have developed a proposal to indicate the availability of cell phone
> service at nodes and areas,
>
On Sun, Jul 30, 2023 at 12:08 PM Marc_marc wrote:
> did we need to have this thread again and again ?
> [...]
Regards,
> Marc
>
What do you believe should go into the name tag of the bodies of water
known in French as océan Atlantique or the body of water known as Itämeri
in Finnish?
Hello,
Comment is requested on a proposal to introduce two tags to indicate the
reason why a name=* tag has been omitted from a feature:
https://wiki.openstreetmap.org/wiki/Proposal:Omitted_name_tag
Please provide feedback here, on the wiki talk page, or on the Community
Forum thread that I
I don't see the current usage to be a problem.
On Sun, Jul 2, 2023, 2:19 PM Asa Hundert wrote:
> I want this amenable to consumers. If I were to propose an attribute
> to the other tag, I'd have to propose to deprecate the uses on areas
> that allows for such atrocities as "amenity=lounger;
un 22, 2023, 8:28 AM Greg Troxel wrote:
> "Brian M. Sperlongano" writes:
>
> > On Thu, Jun 22, 2023, 8:08 AM Illia Marchenko <
> illiamarchenk...@gmail.com>
> > wrote:
> >
> >> But "freeway" is de facto equivalent of motorwa
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 inconsistently. I assure
you that the on the ground
> yes, but motorway is an exception because it is usually defined by signs
> rather than characteristics (e.g. if the signs are missing but it looks and
> feels like, we use motorroad=yes in some countries)
Iknow you said 'usually' but this sounds like a very European perspective
to me. We have
This is a change to longstanding tagging practices and is therefore dead on
arrival.
On Fri, Feb 10, 2023, 11:33 AM Cartographer10 via Tagging <
tagging@openstreetmap.org> wrote:
> Tjuro and I started a proposal to formalize the usage of `landcover=*`.
> The proposal is now open for feedback
>
On Fri, Feb 3, 2023 at 9:45 AM Marc_marc wrote:
> Le 03.02.23 à 15:32, Brian M. Sperlongano a écrit :
> > Let's make sure we're talking about the same thing
>
> what's the issue with tag if TomTom doesn't reply ?
> I suppose it's more for talk than tagging
If it's prom
On Fri, Feb 3, 2023 at 4:23 AM Walker Kosmidou-Bradley <
walker.t.brad...@gmail.com> wrote:
> I understand that having tagging like this does not benefit you, but does
> it hurt you? If it doesn’t hurt you and it may help somebody else is there
> a problem?
>
Hi,
Let's make sure we're talking
?
On Mon, Jan 30, 2023 at 12:49 PM David Salmon
wrote:
> Hi All,
>
>
>
> Thank you for the discussions and pointers. I’ve disabled the challenge
> for now and will re-evaluate with the team.
>
>
>
> Much appreciated,
>
> David
>
>
>
> *From:* Brian M.
I think the point was that the units are explicitly tagged in meters,
whereas in other cases (like ele), the unit assumed to be meters and you
can just put a number by itself.
On Sat, Jan 28, 2023, 3:14 PM stevea wrote:
> Using mm (millimeters) as a unit for this makes no sense. Meters are
On Sat, Jan 7, 2023 at 3:57 PM Martin Koppenhoefer
wrote:
> I have no idea about the situation in France, but there definitely is
> fragmentation in OpenStreetMap channels (slack, telegram, forum, ml, irc,
> facebook etc.) - it is not necessarily a problem.
It is not a problem, but, for the
On Sat, Jan 7, 2023 at 1:00 PM Marc_marc wrote:
> that is what I call a fragmentation, that's what happend
> with the fragmentaiton of the fr community
I was curious about this comment and so I headed over to
openstreetmap.community to check out the list of community spaces in
France. I found
A proposal[1] to recommend the tagging of oceanic seas as nodes rather than
areas is now open for comments.
This proposal follows a community forum discussion[2] regarding the
modeling of the Gulf of Mexico as a node rather than as a crude polygon.
This change was made in [3]. This proposal would
One of the names might be the predominant name used locally.
On Fri, Dec 30, 2022, 2:19 PM Yves via Tagging
wrote:
> Remove the name of the way, put a name on each relations. Except if it
> makes sense to keep the name also on the way for whatever reason you see
> fit.
>
> Le 30 décembre 2022
On Mon, Dec 19, 2022 at 2:15 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:
> foot=use_sidepath was invented to mark "yes, on carriageway you cannot
> walk, but you can walk on separately mapped sidewalk"
>
This makes sense to me, but the wiki[1] is somewhat confusing about
Hello,
On Sun, Dec 18, 2022 at 6:08 PM Jens Glad Balchen
wrote:
>
> There are instances that you wouldn't want to include in your router.
> E.g. https://www.openstreetmap.org/way/658000911, which is similar
> except there is no sidewalk=separate. Walking on this "sidewalk" is
> probably
estrian-in-roadway" ordinances) and
> there is NO sidewalk. In this case there IS an "easement" (whether
> populated by utilities or not) where pedestrians are allowed, because
> pedestrians must be able to use the right-of-way of the road, too. Just
> not IN the roadway,
ave
> a sidewalk?
> Only in a city environment or also in a non-city environment?
> Or in Texas if you're on foot you're going nowhere?
> Definitely not human!
>
>
> Il giorno dom 18 dic 2022 alle ore 22:31 Brian M. Sperlongano <
> zelonew...@gmail.com> ha scritto:
>
&
> (usually car) road-accompanying sidewalk.
>>
>> Also, your project reminds me of wandrer.earth, where craig also
>> introduced a way for running to track ran ways, not only for cyclists.
>> Though i only use it for cycling.
>>
>> --
>> Diese Nach
a way.
> However i would tag foot=use_sidepath, which means the same as foot=no but
> also indicates the existence of a separate way usable for routing.
> And only if the highway is a streets centerline, not a cycleway or other.
>
> Cyton
> Am 18.12.22, 21:32 schrieb "Brian
Hello,
I am the author of a data consumer which generates a list of streets that
are accessible to walkers and joggers. The idea is that a user would have a
map of the streets in their town and can challenge themselves to walk/jog
down every street, and they can look at statistics on which
On Tue, Nov 15, 2022 at 6:22 AM Włodzimierz Bartczak <
wlodzimierz.bartc...@openstreetmap.pl> wrote:
> That's right it's an oversight. I was a bit hasty. First of all, I wanted
> to start a discussion. It would be worthwhile to sort out the use of this
> key. Everyone is complaining about this
It has come to my attention that the "historic" proposal has apparently
been re-opened for a vote without even a courtesy message to the tagging
mailing list. Thank you to user Mnalis to noticing this and alerting
several community members that have previously commented on the proposal.
On Mon, Nov 14, 2022 at 2:49 AM Marc_marc wrote:
> We can see it with the osm-fr experience: the immature forum has split
> the community, far from federating
>
Thank you for clearly describing the root cause of your objection.
In my opinion, it is better to let people decide for themselves
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 activity, it is entirely appropriate to say to a proposer
I support the idea that proposals be posted to both the mailing list and
the community forums. Over time we can assess whether one or the other is
better.
One thing I think is missing is that I would like to see proposals posted
to a dedicated space in the forums that can be subscribed to, that
You should bookmark this site to keep track of proposals:
https://osm-proposals.push-f.com/
Ideally this should probably be linked to more places.
On Sun, Nov 6, 2022 at 7:31 AM ael via Tagging
wrote:
> A very general comment:-
>
> I very seldom consider voting on proposals, but I did want to
On Sat, Nov 5, 2022 at 6:45 PM Robin Burek wrote:
> And if we now get to the point of just "throwing away" the consensus of 12
> years ago.
>
> do we still need the proposal process at all? Because the result from 12
> years ago is also completely ignored by you.
>
it was already decided to
On Sat, Nov 5, 2022 at 5:55 PM Robin Burek wrote:
> What kind of reversal of guilt is that? If someone does not participate in
> the RFC. And it has been discussed both here and in the new forum. Even
> constructive support, which I have received and not a little.
> I have yet to talk to anyone
It is the responsibility of the proposer to ensure that there is a
consensus before moving to a vote, regardless of timelines. It seems to me
that there has been a recent plague of proposals where proposal writers are
tossing proposals into voting status without doing enough due diligence.
If you
I'll offer a well-known example from my country:
https://en.wikipedia.org/wiki/Welcome_to_Fabulous_Las_Vegas_sign
It's on the US National Register of Historic Places which should qualify it
as a historic sign. Although I suppose those in Europe would just consider
the sign to be a little old.
I think I understand the proposal from poking around on the links to the
different alternatives, but could you clarify, for objects currently tagged
man_made=drinking_fountain, what the range of alternative taggings would
be? I almost wish there was a flow chart that would let the mapper of a
The main issue I have with this proposal is that there is a longstanding
controversy regarding the historic key. Namely, the question of whether it
is used for things that are historic or merely old. I don't see how a
proposal centered around this key can move forward with that fundamental
On Sun, Oct 23, 2022 at 10:18 AM Andy Allan wrote:
> Can I reiterate this please - of all the things in OpenStreetMap that
> OSMF gets involved in, tagging is perhaps the thing that OSMF gets
> involved in least of all. So I think this discussion is happening in
> quite the wrong mailing list.
>
I appreciate the effort here, but I think it's too broad. I would rather
have a more focused look at individual keys that considers what the tagging
alternatives are to each, and to assess whether there is duplication and/or
debates surrounding them that are worth investigating. There is really
On Fri, Sep 30, 2022 at 7:45 PM Graeme Fitzpatrick
wrote:
> How about "water bubblers"? Are they also a tap?
>
Ah yes, the "bubbler".
For those that don't live in Rhode Island, or one specific part of
Wisconsin, "bubbler" is a word that we use for what's called a "water
fountain" in other
A commenter on the reservoir proposal[1] pointed out the existence of
quarry lakes[2], which is a lake that is formed after a quarry has been dug
after a mining operation. It was suggested that such bodies of water
should be tagged separately from other lakes with a tag such as
water=quarry.
On Thu, Dec 24, 2020 at 9:00 AM Paul Allen All of which has drifted somewhat off topic, but until we have a
> reasonable understanding of how different legislations handle
> things we don't have a good model of how we ought to go
> about mapping them (or even if we should map them).
>
I'm not
ically measure natural=water size where the way contains a waterfall
> node.
>
> On Thu, 24 Dec 2020, 4:14 pm Brian M. Sperlongano,
> wrote:
>
>> I could see value in tagging them separately. I.e. "I'd like to swim in
>> a small pool with a waterfall".
>>
I could see value in tagging them separately. I.e. "I'd like to swim in a
small pool with a waterfall".
On Thu, Dec 24, 2020, 12:10 AM Andrew Harvey
wrote:
>
>
> On Thu, 24 Dec 2020 at 10:26, Paul Allen wrote:
>
>>
>> Isn't that a plunge pool? https://en.wikipedia.org/wiki/Plunge_pool
>> I
> I think you need to expand a little on how to "conflate" a pool with a
> river. The
> disadvantage of doing so is that the pool then cannot have a name assigned.
>
Sorry, my words were not clear enough here. By "conflate" I mean that the
pool would simply be part of the river polygon. See
Would this work for addressing schemes that use a hyphenated prefix?
In Hawaii, addresses outside of the city of Honolulu use a two-digit prefix
in addresses to determine which sector of the island an address is
located. So an address might be something like "99-123 Kamehameha
Highway". Would
Discussion on the current reservoir proposal[1] (which seeks to define the
distinction between reservoirs, lakes, and ponds) has brought up the
question of stream/plunge pools[2,3], and how they fit into the lake/pond
definitions.
I've come up with the following text:
"Occasionally a river or
On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm wrote:
> Our current data model is not suitable for mapping fuzzy areas. We can
> only do "precise". Also, as you correctly pointed out, or basic tenet of
> verifiability doesn't work well with fuzzy data.
>
The current data model works just fine
I agree with this interpretation. sport=* should always be secondary to
some physical feature that is a location in some way related to the sport
(where it is played, where you can get lessons, a shop, etc).
On Sun, Dec 20, 2020 at 6:32 PM Martin Koppenhoefer
wrote:
>
>
> sent from a phone
>
>
> Yes, but all proposals suggest a rendering scheme.
>
The proposal process wiki page says "Not a part of the proposals process as
such, but hints for the renderer maintainer will help them out. maybe a
description of an icon (refer Map Icons), or an example mock-up. Usually
may be safely omitted
Note that the shooting_range hazard is specifically about the zone in and
around a shooting range that you should avoid if you don't want to
accidentally encounter a stray bullet (the area of the hazard) rather than
as a tag for a shooting range itself.
On Sun, Dec 20, 2020 at 3:30 PM Jmapb
A proposal[1] to clarify the tagging of reservoirs, lakes, and ponds is now
open for comments.
This proposal:
1. Deprecates landuse=reservoir
2. Provides definitions for:
a. water=reservoir
b. water=lake
c. water=pond
It is clear from various multiple discussions on this
> "Hillock" is quite common in British English
To describe a traffic control device?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
These guys in Texas will let you drive their tank around and shoot things,
for a price:
https://www.oxhuntingranch.com/activities/hunting-shooting/machine-gun-shooting/
On Sat, Dec 19, 2020 at 6:16 PM Martin Koppenhoefer
wrote:
>
>
> sent from a phone
>
> > On 19. Dec 2020, at 23:59, Jeremy
>
> is firing ordnance a leisure activity somewhere? Or a sport?
Hello, let me introduce to you the United States of America.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Historic or abandoned military features, or military ruins, are clearly not
what this proposal is describing.
On Sat, Dec 19, 2020 at 5:44 PM Graeme Fitzpatrick
wrote:
> On Sun, 20 Dec 2020 at 02:00, St Niklaas wrote:
>
>>
>> Your text or proposal seems to be focused on modern times.
>>
>
>
Perhaps simply leisure=range, as this would be generic to any type of
facility where one might fire projectiles or ordnance. You could then
extend that with something like range= to specify what is being fired,
and/or the existing sport= key if it's considered a shooting sport.
On Sat, Dec 19,
I've seen these in the US also, but I never knew what they were called. I
understand that the purpose of them is simply to make noise when a car
drives over them, as they don't slow you down in any appreciable way like a
speed bump/hump.
We already have a tag for "a traffic calming device that
I understand pitch to mean "a playing field" (as "pitch" is not often used
in US English -- we would say "soccer field" for example.). I don't know
if a shooting range is a pitch or not, but it definitely isn't a playing
field.
On Sat, Dec 19, 2020 at 3:35 PM Paul Allen wrote:
> On Sat, 19 Dec
With respect to basins, my understanding is that some of these have water
in them all of the time, some of them have water some of the time, and then
there are some that are almost always dry, but become wet only rarely when
they are needed (e.g. for stormwater handling)
Mappers have used BOTH
hazard=yes is neither banned nor discouraged. It was simply not included
in the list of proposed approved tags due to objections raised during the
RFC. The goal was to approve the hazard tagging that everyone agreed on.
Since hazard=yes has some existing tagging (>600 uses), it would still be
I knew them as sewage treatment ponds, but apparently there's a name for
them:
https://en.m.wikipedia.org/wiki/Waste_stabilization_pond
I feel like this a separate class of object that deserves its own tag,
either within or separate from natural=water, or perhaps even subclassed as
alifornia%20highway%201%20curves%20for%20next%2074%20miles=firefox-b-d=2ahUKEwifs6ryz9PtAhUO16QKHZ2-AjEQMygAegQIARAu>
>
>
>
>
> On Wed, 16 Dec 2020 at 23:13, Brian M. Sperlongano
> wrote:
>
>> As the maintainer of the current hazard proposal - I don't really have
>> stron
As the maintainer of the current hazard proposal - I don't really have
strong opinions about signed versus unsigned hazards, though I know others
do. However, signed hazards seem to be something that we all agree should
be tagged, and this proposal is attempting to approve the collection of
+1
IMHO these are complementary. waterway=rapids can be tagged from overhead
imagery, and the additional detail of the rapids can be added later by
people with subject matter expertise.
I see this as equivalent to sac_scale=* for hiking trails - it does not
replace the underlying highway=path,
The statistics reflect all areas, regardless of which editors were used to
create them. I stand by them, as numbers do not lie. There was a 3:1
preference for water=reservoir during 2017 and 2018, two years prior to the
change in iD preset. The data is open, and taginfo provides a very helpful
Tomas,
Since you are not willing to accept (1) an existing approved proposal, (2)
new proposal to correct flaws in the first one, or (3) the overwhelming
preference of the mapping community over the past four years[1], then I'm
sorry but we must curtly dismiss your arguments as a one-man
-12-16, tr, 01:32 Brian M. Sperlongano rašė:
> > The iD editor preset appears to use water=reservoir while the JOSM
> > preset appears to use landuse=reservoir.
>
> Not entirely correct.
> * JOSM gives freedom to mappers and supports BOTH.
> * iD forces to use water=re
Thanks everyone for the discussion.
I believe there are two germane points being raised by Tomas that warrant
our consideration:
1. It is not clear from the original 2011 vote which created
water=reservoir (and other values) as to whether the community intended to
deprecate landuse=reservoir or
Wouldn't it be more consistent to keep it in the same key, and call it
place=lake_group? Or even place=lakes?
Would this be used for something like the Great Lakes in USA/Canada or is
that too large of a feature?
On Tue, Dec 15, 2020, 12:05 PM stevea wrote:
> +1. Joseph's suggestion is a
Hello,
I recently received late feedback on the hazards proposal. Based on the
feedback, I felt it was necessary to make small changes to this proposal.
I believe these changes are sufficiently minor that they do not invalidate
the voting which has occurred so far. Since this proposal has begun
On Mon, Dec 14, 2020 at 5:11 PM François Lacombe
wrote:
> Hi Brian,
>
> Thank you for your comments
>
> Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano
> a écrit :
>
>> 1. The proposal states "It is proposed to discourage the use of
>> undocumente
I agree with Mateusz that the wiki IS the project's standard document for
the meaning of tagging (from the perspective of data consumers) and how to
tag (from the perspective of mappers). Note that both perspectives are
important. But to address the specific point, there is no standard
document
It sounds like what we are asking for is the ability to tag a rough polygon
in the approximate area where a label should be placed for a known but not
strictly bounded toponymic feature (mountain range, water body, etc). That
would give a hint to renderers as to the location and most importantly,
François, thank you for your hard work on this proposal! I will most
likely support this version. I have a few questions:
1. The proposal states "It is proposed to discourage the use of
undocumented pump:type=* to state pump mechanisms in favour of new
pump_mechanism=*." It is not clear what
I will note that the Massachusetts, USA mapping community does believe that
there is a distinction between the two tags, as noted here:
https://wiki.openstreetmap.org/wiki/Massachusetts/Conservation
However, this usage and definition seems to be specific to that particular
community and is not a
for the same
reason - working together to create the best possible map for the world.
[1] https://josm.openstreetmap.de/ticket/17874
[2] https://github.com/openstreetmap/iD/issues/6589
On Sun, Dec 13, 2020 at 10:39 AM Tomas Straupis
wrote:
> 2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
>
This story is offered because I find it interesting, and as a possible
catalyst for updates to our tagging documentation. I offer apologies to
those that are well aware of this controversy.
There are two competing ways to tag reservoirs: landuse=reservoir, or
natural=water + water=reservoir.
> Break - I've just found that there actually are a handful of
> club=army_cadets (8), =air_cadets (5) & =sea_cadets (2) already in use,
> although all are undocumented, so they will be fine. Are we all in
> agreement though, that there should be no reference to "military" against
> Cadet groups
Hello,
Voting is now open for a two-week period on the proposal "Hazards". I wish
to express my sincere appreciation to the many of you that provided
valuable input during the development of this proposal.
Voting link:
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard#Voting
Hello Anders,
I would recommend creating a multipolygon relation (type=multipolygon) with
each of the wetland pieces, and set the name= and appropriate natural= and
wetland= tags on the relation.
On Fri, Dec 11, 2020, 11:11 AM Anders Torger wrote:
> Hello,
>
> I was on this list a while back
>
> Ground/land, air/aviation & maritime/naval all seem pretty well
> interchangeable, space is ready for the future & we should also include
> amphibious & probably Staff / Command / Headquarters for somewhere like
> this place: https://www.openstreetmap.org/relation/89605! Currently
>
In general I have avoided proposing values for these "warning of something
ahead" signs that are at a non-trivial distance from the hazard, as I think
that is a controversial usage, deserving of a separate discussion and/or
proposal. Since there is already a tag for cattle grids and there is no
>
>
> Services often cross functions; for example, the US Army operates air
>> fields[2]. Tagging this military_service=army would be accurate, but would
>> not convey that this is an air force base, but not an Air Force base.
>>
>> To get around all of this, we should tag military bases with
> The Wikipedia pages on the Royal Navy, Royal Air Force and British Army
>> use "military service"
>>
> sometimes too, and mention the overall "British Armed Services", "Her
>> Majesty's Naval Service", etc.
>>
>
> The same goes for the dialect spoken by that page's author.
>
> However, whilst
"Service" is the right term for what is being described (e.g. army, navy,
air force, etc), and is consistent with UK terminology[1].
However, it also assumes that every country's military forces are neatly
grouped into these categories. The Chinese military is particularly
complex - the Chinese
>
> We have examples in the UK, even on major roads like the A346 between
> Marlborough and Swindon. I don't think they are tagged.
> with sophisticated routers issuing an alarm on approach might be
> something in the future. These dips are clearly signed.
>
You've just convinced me that this
> Here are the ones that I think are worth considering:
>
>- Opening or swing bridge ahead
>
> This is already covered by the approved tag bridge:movable and its various
sub-keys that describe different types of movable bridges. There were no
existing usages I could find under the hazard key,
> I'd suggest fallen_rock and low_flying_aircraft as tag values based upon
>
the common case but have the proposal mention their secondary application.
>
I actually have low_flying_aircraft in the proposal as a value, though I
just discovered that there is a more common value in use,
81425).jpg
[2] https://commons.wikimedia.org/wiki/File:NYS_NYW4-14.svg
On Wed, Dec 9, 2020 at 8:37 AM Paul Allen wrote:
> On Wed, 9 Dec 2020 at 13:13, Brian M. Sperlongano
> wrote:
>
> Add hazard=falling_rocks, landslide; deprecate rock_slide, rockfall
>>
>
> Kev
Thanks to all who have spilled much ink and provided extensive comment on
this proposal[1] -- the feedback is deeply appreciated as it increases
confidence that the proposal reflects community consensus. The hazard tag
has attracted an additional 2,000 usages just over the course of this RFC,
and
I fixed that for you, it should just be status=proposed, and the template
does the rest of the magic!
On Mon, Dec 7, 2020 at 7:26 PM Graeme Fitzpatrick
wrote:
>
>
>
> On Tue, 8 Dec 2020 at 10:19, Graeme Fitzpatrick
> wrote:
>
>>
>> I have just posted a new proposal re Military Bases:
>>
at=53.50421582735714=14.477556379223921=17=photo=aaBuvm_A9utc1PYDRyGyXw=0.5085941428184124=0.5962547075134255=0
On Sun, Dec 6, 2020 at 6:45 PM Martin Koppenhoefer
wrote:
>
>
> sent from a phone
>
> > On 7. Dec 2020, at 00:17, Brian M. Sperlongano
> wrote:
> >
> > The
The largest existing use of hazard=cyclists is in Germany. There is no
Google StreetView in Germany, but from the small number examples [1] I
looked at, it seems like this tag is being used for "cyclists in the road"
hazards and not "cyclist crossings". There were only 10 usages of the tag
(out
The hazard proposal [1] currently proposes hazard=cyclists as a way to tag
a signed area in which motorists should watch for or share the road with
cyclists. Note that this is explicitly different from a cyclist crossing,
which is currently covered by highway=crossing.
It was suggested by a
Yes, and while we're at it, let's throw in multinational bases as well:
https://en.wikipedia.org/wiki/NATO_Air_Base_Geilenkirchen
On Sun, Dec 6, 2020 at 11:17 AM Paul Allen wrote:
> On Sun, 6 Dec 2020 at 16:01, Brian M. Sperlongano
> wrote:
>
>> This is probably a US-centric v
1 - 100 of 162 matches
Mail list logo
