Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Georg Feddern]

Am 27.03.2017 um 17:29 schrieb Martin Koppenhoefer:


2017-03-27 16:34 GMT+02:00 Marc Gemis >:


In the case you have added e.g. a stop sign on the way. A second
mapper comes in, splits the way on the stop sign, reverts the
direction of one of the spit parts. Now the node is at the end of 2
ways with different direction and one cannot know what is
forward/backward in that node. But any good editor can give a
warning/error for such a case.



yes, the editor can issue a warning, but what should be the reaction 
then? Shall we discourage changing way directions because of a stop 
sign node on this way? Usually there's a good reason for people 
changing way directions, adding more complexity to these changes with 
highway signs depending on them is not necessary.


It is just a warning, that this is one of the seldom situations where 
you need a relation - just check, obey and ignore afterwards.

Furthermore the editor can check for the relation too.

Yes there is a possibillity for such a situation, but I doubt they would 
be essentially - and it can be solved by a relation.
But a pure possibility should not effect the majority of simple 
situations - it is OSM-like to consider simple solutions and spare 
relations for the difficult ones only.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] named spots in settlements (toponyms)

[Warin]

On 28-Mar-17 03:12 AM, Martin Koppenhoefer wrote:
In a recent changeset discussion, we have concluded that the best 
thing might be asking here for opinions.


This question is about toponyms. Usually these are tagged within the 
place-tags (some might be found in "natural" etc.). Someone wants to 
map named spots in the city, although there are no signs, these names 
are commonly known in the town (one name derives for example from a 
former shop at this spot, another name from a student's fraternity 
nearby). These are points, not areas (in reality), and they do not 
refer to settlement parts, so the tagging that is currently applied 
(place=neighbourhood) doesn't seem right.


One alternative could be place=locality. The wiki writes that locality 
is about "unpopulated places", and I am not sure how to interpret 
this. Is this to exclude settlements and their parts (i.e. the object 
with this tag shall not represent something with population), or is it 
about the location (outside vs. inside of a settlement)?


Shall we make the wiki for place=locality clearer, or should we invent 
a new place value for named spots inside populated areas?




I would leave place=locality alone.
If you need assistance you would not go to an unpopulated place, if 
locality is changed to include populated places then the map would be 
less clear.


The other problem is that this 'feature' may have no physical presence 
("a former shop at this spot") and so may not be easily verifiable .. 
possibly a history tag for these.. or dismantled ?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Jean-Marc Liotier]

(Sent again, this time without all the cc: which probably are the
cause of the previous attempt being held in the listserv's spam filters...
After eleven hours I guess it won't be delivered to the list so I resend)

On Fri, 24 Mar 2017 19:08:13 +0100
yo paseopor  wrote:
>
> I would start a "definitive thread" with all the options, all the
> possibilities, all the points of view, all the information and then,
> passing all to the wiki with a votting or aproved by list complete
> proposal.

Well, heres is an attempt... At some point one may wish to paste it
into a wiki page. In cc: the participants in the threads recently
discussing this subject.

So, here is a summary of the methods that, after discussion here, seem
to have some traction among participants for the mapping of "stop"
restrictions and similar restrictions such as "give_way" and
"traffic_signals". This is about the restriction, not the sign that
advertises it. It applies to two-ways way, in cases other than an
all-ways restriction. I omitted some methods mentioned which seem too
ambiguous, too heavy on processing, lacking current use or all of the
above.


1- highway=stop+direction=forward node on the way to an intersection

Documented at https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
and https://wiki.openstreetmap.org/wiki/Tag:highway%3Dgive_way

Advantages:
- Only one additional tag
- Uses the widely used direction=* tag

Disadvantages:
- To be unambiguous, must be tagged on a non-intersection node
  adjacent to the intersection to which it applies
- Only good for covering simple cases: complex case require
  a more powerful method such as the relation (type:enforcement)
- direction=* is also used for cardinal directions, so two
  semantic fields coexist within the same tag


2- highway=stop+stop:direction=forward node on the way to an
  intersection

Documented at
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals

Advantages:
- Only one additional tag
- Uses the *:direction=* scheme which is widely used for
  traffic_signals:direction=* and stop:direction=* and might
  therefore be unified later. Also used for railway signals.
- Cognate to the way Kendzi3D models signs

Disadvantages:
- To be unambiguous, must be tagged on a non-intersection node
  adjacent to the intersection to which it applies
- Only good for covering simple cases: complex case require
  a more powerful method such as the relation (type:enforcement)


3- relation (type:enforcement)
Documented at https://wiki.openstreetmap.org/wiki/Relation:enforcement

Advantages:
- The only method to unambiguously covers all cases
- Few additional tagging steps: creating the relation and adding a
  couple members covers the simple case
- Compatible with the node bearing the highway=* restriction being
  either on the way or elsewhere at the actual location of the sign

Disadvantages:
- A couple more additional tagging steps compared to
  the other methods
- It is a relation (relations are perceived as not
  beginner-friendly, and some consumers don't grok them)

My opinion is that method #3 must be promoted but current practice
hints that it might have to coexist with one of the two others (or both
if no convergence consensus emerges).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

El 27/03/17 a las 16:48, Juan Pablo Tolosa Sanzana escribió:

>>/It is a bay of the Tasman Sea/Pacific Ocean. Ecologically it is a fully /> 
maritime waterbody.
>
> What do you mean by "maritime waterbody"?

A maritime waterbody are all those waters under the influence of the tides. You can 
review article for natural=coastline. The coastline should be placed in the "high 
water mean spring":https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline


> If you're in Botany Bay or the other bays there such as
> https://www.openstreetmap.org/relation/1333569, 
  you're not at sea or

> in the sea, or in the ocean.

Botany Bay is part of the ocean, not a separate inland waterbody. You can see 
in the terrain the mark of the tides.
  
> If you swim at a coastal beach you're swimming in the sea and the

> ocean. At the beaches of Botany Bay, no one would say you're in the
> sea or ocean. Nor would they say you're on the coast of Australia.

This is only a colloquial thing. That lacks of verifiability. For example, Dead 
Sea is not a sea, really is a lake.

> Botany Bay is unlike many conventional bays which are on the coastline
> and part of the sea. You're right that these types of bays are part of
> the sea and ocean, and other times they are part of a river, but
> botany bay is really a river nor sea, if anything Botany Bay sounds
> much more like an Esturary.https://en.wikipedia.org/wiki/Estuary

The rules for tagging are in the OSM wiki. Even in Wikipedia says Botany Bay is 
an oceanic bay:https://en.wikipedia.org/wiki/Botany_Bay
The coastline is a natural feature. You don't mix it with political things. You 
can use the tag boundary=maritime + maritime=base_line to delineate political 
inner waters. Even the boundary runs in the mouth of Botany Bay, therefore is 
respected local things that you mean.
Here there are instructions to tag an 
estuary:https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement


Sorry, in the last paragraph is boundary=maritime + border_type=baseline 
for outer edge of internal waters.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging town/village/hamlet - am I misunderstanding something?

[Kevin Kenny]

On Mon, Mar 27, 2017 at 12:57 PM, Brad Neuhauser 
wrote:

> Two issues:
>
> 1) Recommended OSM tagging for place=* on smaller settlements is on the
> wiki: http://wiki.openstreetmap.org/wiki/Key:place#Populated_
> settlements.2C_urban_and_rural  You can see it's based mainly on
> population and is not directly correlated to the form of government. Seems
> like admin_level=* is the place for levels of government--see
> http://wiki.openstreetmap.org/wiki/United_States_admin_level  (Ft
> Montgomery has a population of about 1500, so I'd agree with Martin to tag
> it as place=village.)
>

OK, it's a village (OSM's term, but not a political Village) with
admin_level=8. Got it. 'Suburb' is also plausible - there are a fair number
of people there who commute to New York City from Peekskill - but 'village'
probably fits the definition on the Wiki better.


> 2) The rendering of labels for places varies. If you take a look at the
> area on the four map layers on osm.org, a Fort Montgomery label appears
> 0, 1, or 2 times. So tag for what it is, not for rendering.
>

The render queue is not necessarily current on the other maps.When I looked
at the Humanitarian map just now, I saw the Fort Montgomery label, and a
Shift-Reload made it disappear (while making the park and military
reservation boundaries start to look correct). The only zoom level on
Humanitarian where I see Fort Montgomery labeled is zoom level 13, and
there I still see the incorrect boundaries for the military reservation and
the park that triggered this whole exercise. (Zoom levels 12 and 14 have
good boundaries, but no label on Ft Montgomery.)

I see the label on the transport map,. but the park boundaries are even
farther out of date - it looks as if that hasn't been re-rendered in weeks
- it's missing the oblong parcel of Bear Mountain State Park north of the
village.

You're right that Open Cycle Map is showing the name.

In any case, I wasn't looking to tag for the renderer, merely taking the
changed rendering as a warning that I might have mistagged. In fact, for
my own use, I don't ordinarily use any of the OSM renderings, but
something more like
https://kbk.is-a-geek.net/catskills/test3.html?la=41.3340=-73.9785=15
(And I recently came to realize that I'm rendering place names only for
points, and wondering whether I should fix that.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

/It is a bay of the Tasman Sea/Pacific Ocean. Ecologically it is a fully /> 
maritime waterbody.


What do you mean by "maritime waterbody"?


A maritime waterbody are all those waters under the influence of the tides. You can 
review article for natural=coastline. The coastline should be placed in the "high 
water mean spring": https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline



If you're in Botany Bay or the other bays there such as
> https://www.openstreetmap.org/relation/1333569, 
  you're not at sea or

in the sea, or in the ocean.


Botany Bay is part of the ocean, not a separate inland waterbody. You can see 
in the terrain the mark of the tides.
 

If you swim at a coastal beach you're swimming in the sea and the
ocean. At the beaches of Botany Bay, no one would say you're in the
sea or ocean. Nor would they say you're on the coast of Australia.


This is only a colloquial thing. That lacks of verifiability. For example, Dead 
Sea is not a sea, really is a lake.


Botany Bay is unlike many conventional bays which are on the coastline
and part of the sea. You're right that these types of bays are part of
the sea and ocean, and other times they are part of a river, but
botany bay is really a river nor sea, if anything Botany Bay sounds
much more like an Esturary.https://en.wikipedia.org/wiki/Estuary


The rules for tagging are in the OSM wiki. Even in Wikipedia says Botany Bay is 
an oceanic bay: https://en.wikipedia.org/wiki/Botany_Bay
The coastline is a natural feature. You don't mix it with political things. You 
can use the tag boundary=maritime + maritime=base_line to delineate political 
inner waters. Even the boundary runs in the mouth of Botany Bay, therefore is 
respected local things that you mean.
Here there are instructions to tag an estuary: 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging town/village/hamlet - am I misunderstanding something?

[Brad Neuhauser]

Two issues:

1) Recommended OSM tagging for place=* on smaller settlements is on the
wiki:
http://wiki.openstreetmap.org/wiki/Key:place#Populated_settlements.2C_urban_and_rural
You can see it's based mainly on population and is not directly correlated
to the form of government. Seems like admin_level=* is the place for levels
of government--see
http://wiki.openstreetmap.org/wiki/United_States_admin_level  (Ft
Montgomery has a population of about 1500, so I'd agree with Martin to tag
it as place=village.)

2) The rendering of labels for places varies. If you take a look at the
area on the four map layers on osm.org, a Fort Montgomery label appears 0,
1, or 2 times. So tag for what it is, not for rendering.

Brad


On Mon, Mar 27, 2017 at 11:33 AM, Kevin Kenny 
wrote:

> On Mon, Mar 27, 2017 at 11:47 AM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>> As a side note, your example Fort Montgomery, NY, to me doesn't look like
>> a hamlet, there's an elementary school, shops, a fire department, gas
>> station, hotel, cafe, sports grounds, and a significant amount of houses, I
>> would consider calling this a village.
>>
>
> Local convention in New York is to follow the legal definitions. Fort
> Montgomery is legally a hamlet.  New York has a few 'hamlets' that are
> actually small cities. (Levittown, population about 52,000, is the largest
> of these.) Villages, towns, and cities are incorporated places with their
> own local governments. Hamlets have no local government other than the
> township and county that they're in.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging town/village/hamlet - am I misunderstanding something?

[Martin Koppenhoefer]

2017-03-27 18:33 GMT+02:00 Kevin Kenny :

> Local convention in New York is to follow the legal definitions. Fort
> Montgomery is legally a hamlet.  New York has a few 'hamlets' that are
> actually small cities. (Levittown, population about 52,000, is the largest
> of these.)



I understand that legal definitions are important, but IMHO the OSM tag
place=hamlet is not about this property that NY law is about. My suggestion
would be to use a distinct tag like (just an example) incorporated=yes/no.
>From what I read in wikipedia, the term "hamlet" is not defined in NY law:
https://en.wikipedia.org/wiki/Administrative_divisions_of_New_York#Hamlet
(note that this is still about administrative divisions, something we
should cover in boundary=administrative and admin_level tags).

If some place you call "actually a small city" (52000 population) is tagged
as hamlet it creates problems for all data users (e.g. the label is too
small and showns too late compared to similar places with different
administrative organisation).

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] named spots in settlements (toponyms)

[yvecai]

It's unfortunate the wiki definition of place=neighbourhood defintion 
allows 'fluid borders' and 'well-defined legal and administrative 
borders' at the same time.


Having a tag for informally named places would be a good idea, if the 
*informal* nature survives the wiki definition subsequent edits.
Place=locality covers this for the countryside, so I guess this 
tagshould be populated places-only.


Yves

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging town/village/hamlet - am I misunderstanding something?

[Kevin Kenny]

On Mon, Mar 27, 2017 at 11:47 AM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:

> As a side note, your example Fort Montgomery, NY, to me doesn't look like
> a hamlet, there's an elementary school, shops, a fire department, gas
> station, hotel, cafe, sports grounds, and a significant amount of houses, I
> would consider calling this a village.
>

Local convention in New York is to follow the legal definitions. Fort
Montgomery is legally a hamlet.  New York has a few 'hamlets' that are
actually small cities. (Levittown, population about 52,000, is the largest
of these.) Villages, towns, and cities are incorporated places with their
own local governments. Hamlets have no local government other than the
township and county that they're in.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] named spots in settlements (toponyms)

[Martin Koppenhoefer]

In a recent changeset discussion, we have concluded that the best thing
might be asking here for opinions.

This question is about toponyms. Usually these are tagged within the
place-tags (some might be found in "natural" etc.). Someone wants to map
named spots in the city, although there are no signs, these names are
commonly known in the town (one name derives for example from a former shop
at this spot, another name from a student's fraternity nearby). These are
points, not areas (in reality), and they do not refer to settlement parts,
so the tagging that is currently applied (place=neighbourhood) doesn't seem
right.

One alternative could be place=locality. The wiki writes that locality is
about "unpopulated places", and I am not sure how to interpret this. Is
this to exclude settlements and their parts (i.e. the object with this tag
shall not represent something with population), or is it about the location
(outside vs. inside of a settlement)?

Shall we make the wiki for place=locality clearer, or should we invent a
new place value for named spots inside populated areas?

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging town/village/hamlet - am I misunderstanding something?

[Martin Koppenhoefer]

2017-03-27 16:38 GMT+02:00 Kevin Kenny :

> But now I see that the places - for example, Fort Montgomery, NY
> http://www.openstreetmap.org/relation/175462 - no longer have their names
> rendered on the map. Are municipalities a special case, where the point tag
> has to be retained to represent the 'town center'?  If so, I've only
> touched at most a handful of them, and I'll be happy to put the points back.
>


IMHO if you add place=city/town/village/hamlet to an administrative polygon
like this, you might not gain a lot, because you could already see by
looking at the admin_level what kind of entity it is, or maybe I miss
something (I don't know the particularities of the US)? From my
understanding, the administrative polygons show the borders of all land,
the settlement and the surroundings, while a potential
place= polygon could show only the built up space
(probably including the other settlement parts like zoos, parks, etc.).

Similarly, I have never understood those place values that have been
created for entities that are already dealt with by administrative
polygons, namely country, state, county, municipality, region, district,
borough, ...

As a side note, your example Fort Montgomery, NY, to me doesn't look like a
hamlet, there's an elementary school, shops, a fire department, gas
station, hotel, cafe, sports grounds, and a significant amount of houses, I
would consider calling this a village.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Martin Koppenhoefer]

2017-03-27 16:34 GMT+02:00 Marc Gemis :

> In the case you have added e.g. a stop sign on the way. A second
> mapper comes in, splits the way on the stop sign, reverts the
> direction of one of the spit parts. Now the node is at the end of 2
> ways with different direction and one cannot know what is
> forward/backward in that node. But any good editor can give a
> warning/error for such a case.
>


yes, the editor can issue a warning, but what should be the reaction then?
Shall we discourage changing way directions because of a stop sign node on
this way? Usually there's a good reason for people changing way directions,
adding more complexity to these changes with highway signs depending on
them is not necessary.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Kevin Kenny]

On Mon, Mar 27, 2017 at 10:34 AM, Marc Gemis  wrote:

> On Mon, Mar 27, 2017 at 4:21 PM, Kevin Kenny
>  wrote:
> > I'm having a hard time picturing any case where this couldn't work.
>
> In the case you have added e.g. a stop sign on the way. A second
> mapper comes in, splits the way on the stop sign, reverts the
> direction of one of the spit parts. Now the node is at the end of 2
> ways with different direction and one cannot know what is
> forward/backward in that node. But any good editor can give a
> warning/error for such a case.
>

Exactly. JOSM and Meerkartor surely have more sophisticated checks than
that already. In fact, finding that case is an easier check than anything
involving the 'nearest intersection' rule, which could be broken any time
that someone adds, say, a driveway close to the intersection. That's a lot
harder for an editor to check for. Enumerating nodes along a reversed way
and checking that you haven't changed the direction of a traffic control is
trivial by comparison.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Tagging town/village/hamlet - am I misunderstanding something?

[Kevin Kenny]

Over the last year or two, I've imported or revised or conflated a lot of
public recreational facilities (parks, recreation grounds, nature reserves,
etc... ranging from urban sites of less than 1000 square metres up to
massive wilderness areas of hundreds of square km).

In many cases, I've found point tags for the sites, often imported from
GNIS, but also placed by mappers who wished to show the site but were
uncertain about its boundaries. In those cases, I've made it a practice to
copy the GNIS tagging to the (multi)polygon representing the land area of
the site, thus preserving the cross references to GNIS and Wikidata.
Similarly, if the site was present from a TIGER import, I copied the TIGER
tagging to the new (multi)-polygon.

Recently, I had occasion to tweak a few town/village/hamlet boundaries.
(TIGER had them conflated with the boundaries of nearby parks and military
reservations, which were, of course, incorrect, and so I was sorting out a
complicated mess of conflicting imports.) As I repaired the boundaries, I
noticed that there were GNIS points for the hamlets, and so when I repaired
the boundaries, I transferred the GNIS tagging to the area, and removed the
point. I had thought that was the right thing to do.

But now I see that the places - for example, Fort Montgomery, NY
http://www.openstreetmap.org/relation/175462 - no longer have their names
rendered on the map. Are municipalities a special case, where the point tag
has to be retained to represent the 'town center'?  If so, I've only
touched at most a handful of them, and I'll be happy to put the points back.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Marc Gemis]

On Mon, Mar 27, 2017 at 4:21 PM, Kevin Kenny
 wrote:
> I'm having a hard time picturing any case where this couldn't work.

In the case you have added e.g. a stop sign on the way. A second
mapper comes in, splits the way on the stop sign, reverts the
direction of one of the spit parts. Now the node is at the end of 2
ways with different direction and one cannot know what is
forward/backward in that node. But any good editor can give a
warning/error for such a case.

m

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Kevin Kenny]

I still think that for the overwhelming majority of STOP and YIELD
(give_way) signs, the tagging scheme of a node either on the intersection
or near the intersection on the approaching way makes sense.

And in fact, I think that a fairly simple rule of interpretation actually
answers those who complain that the approach of tagging a node makes no
graph-theoretic sense. I contend that it does. A vehicle finding its way in
our navigation model traces a path from edge (a segment of a way between
two nodes) to vertex (a node) to edge to vertex ... from its origin to its
destination.

It is true that nodes have no direction, but edges do.

I'd say that the simplest interpretation that could possibly work for
'stop' or 'give_way' is:

(1) If there is no direction, the regulation applies to any vehicle
approaching the node from any incident way.
(2) If there is a direction (forward or backward), the regulation applies
to a vehicle approaching the node in the corresponding direction on the way.

For the simplest case of an ordinary traffic light or a four-way STOP, a
simple tag on the intersection suffices.

For the case of a STOP or YIELD (give_way) sign on a side street, place a
node near the intersection, tag it with the sign, and mark it with the
appropriate direction.

For the case of a STOP sign or traffic signal guarding a narrow bridge or
single-lane way, the node can still be on the way and have the appropriate
direction tag.

Obviously, if we are using the node for other purposes, we may need to
disambiguate with stop:direction=* or give_way:direction=*, just as we do
with other ambiguously-named tags.

I'm having a hard time picturing any case where this couldn't work. It
doesn't involve measuring distances to intersections, trying to divine from
a sign placement beside a way what it means for traffic on the way, or any
other weird preprocessing.

I could explain it to a novice mapper in two minutes.

For the occasionally truly weird case (e.g., traffic moving ahead or
turning left must stop; traffic turning right gives way to left turns from
the oncoming way, or something like that) we still have the proposed
relation schemata available, but I really don't get why we feel we have to
impose those on the bog-standard two- or four-way STOP.

On Mon, Mar 27, 2017 at 8:30 AM, Jean-Marc Liotier  wrote:

> On Mon, 27 Mar 2017 14:08:55 +0200
> Topographe Fou  wrote:
> >
> > When you say direction=forward I assume it is forward/backward and
> > not other direction values.
>
> Yes.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Kevin Kenny]

I don't think it does to be too fussy about what is 'river' and what is
'sea' and what is 'estuary'.

Near where I live, a hydrologist would classify the Hudson River as
'estuary' as far as http://www.openstreetmap.org/way/90929525 because it
has a measurable tide right up to that point. Nevertheless, it's fresh
water (the salt front is at least 100 km downstream even in a dry summer),
The actual meeting of river (which, by then, is indeed salt) and ocean is
another 100 km downstream from there.

The locals would be astonished if you were to claim that the bank of the
Hudson River is 'seacoast', even if it has a tide and ships of considerable
size can navigate the river as far as the Port of Albany. A hydrologist
would say, "well, technically, that's correct" and the locals would roll
their eyes.

On Mon, Mar 27, 2017 at 10:05 AM, Kevin Kenny 
wrote:

> I don't think it does to be too fussy about what is 'river' and what is
> 'sea' and what is 'estuary'.
>
> Near where I live, a hydrologist would classify the Hudson River as
> 'estuary' as far as http://www.openstreetmap.org/way/90929525 because it
> has a measurable tide right up to that point. Nevertheless, it's fresh
> water (the salt front is at least 100 km downstream even in a dry summer),
> The actual meeting of river (which, by then, is indeed salt) and ocean is
> another 100 km downstream from there.
>
> The locals would be astonished if you were to claim that the bank of the
> Hudson River is 'seacoast', even if it has a tide and ships of considerable
> size can navigate the river as far as the Port of Albany. A hydrologist
> would say, "well, technically, that's correct" and the locals would roll
> their eyes.
>
>
>
> On Mon, Mar 27, 2017 at 9:28 AM, Christoph Hormann  wrote:
>
>> On Monday 27 March 2017, Andrew Harvey wrote:
>> > > It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a
>> > > fully
>> >
>> > maritime waterbody.
>> >
>> > What do you mean by "maritime waterbody"?
>>
>> A waterbody where plant and animal life matches or is close to that of
>> the sea rather to that of a river or lake.
>>
>> > Botany Bay is unlike many conventional bays which are on the
>> > coastline and part of the sea. You're right that these types of bays
>> > are part of the sea and ocean, and other times they are part of a
>> > river, but botany bay is really a river nor sea, if anything Botany
>> > Bay sounds much more like an Esturary.
>> > https://en.wikipedia.org/wiki/Estuary
>>
>> In OSM we have no separate tagging for estuaries, this would not make
>> sense because it would just introduce yet another boundary problem
>> (where the river turns into the esturary and where the esturary turns
>> into the ocean).  An esturary is the transit of a river into the ocean.
>> If you consider the Botany Bay to be part of the esturary of Georges
>> River you still have to decide where you place the coastline and if you
>> place it below the bay you have to tag the bay waterway=riverbank or
>> natural=water + water=river.  Creating a separate waterbody that is not
>> part of the river but within the coastline is wrong in our current
>> tagging scheme.
>>
>> Note in general the esturary of Georges River would be considered to
>> start much further upstream, likely somewhere around here:
>>
>> https://www.openstreetmap.org/#map=15/-33.9765/151.0237
>>
>> at the transit from a meandering river to a ria
>> (https://en.wikipedia.org/wiki/Ria).
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Christoph Hormann]

On Monday 27 March 2017, Andrew Harvey wrote:
> > It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a
> > fully
>
> maritime waterbody.
>
> What do you mean by "maritime waterbody"?

A waterbody where plant and animal life matches or is close to that of 
the sea rather to that of a river or lake.

> Botany Bay is unlike many conventional bays which are on the
> coastline and part of the sea. You're right that these types of bays
> are part of the sea and ocean, and other times they are part of a
> river, but botany bay is really a river nor sea, if anything Botany
> Bay sounds much more like an Esturary.
> https://en.wikipedia.org/wiki/Estuary

In OSM we have no separate tagging for estuaries, this would not make 
sense because it would just introduce yet another boundary problem 
(where the river turns into the esturary and where the esturary turns 
into the ocean).  An esturary is the transit of a river into the ocean.  
If you consider the Botany Bay to be part of the esturary of Georges 
River you still have to decide where you place the coastline and if you 
place it below the bay you have to tag the bay waterway=riverbank or 
natural=water + water=river.  Creating a separate waterbody that is not 
part of the river but within the coastline is wrong in our current 
tagging scheme.

Note in general the esturary of Georges River would be considered to 
start much further upstream, likely somewhere around here:

https://www.openstreetmap.org/#map=15/-33.9765/151.0237

at the transit from a meandering river to a ria 
(https://en.wikipedia.org/wiki/Ria).

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Jean-Marc Liotier]

On Mon, 27 Mar 2017 14:08:55 +0200
Topographe Fou  wrote:
>
> When you say direction=forward I assume it is forward/backward and
> not other direction values.

Yes.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Andrew Harvey]

> It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a fully
maritime waterbody.

What do you mean by "maritime waterbody"?

If you're in Botany Bay or the other bays there such as
https://www.openstreetmap.org/relation/1333569, you're not at sea or
in the sea, or in the ocean.

If you swim at a coastal beach you're swimming in the sea and the
ocean. At the beaches of Botany Bay, no one would say you're in the
sea or ocean. Nor would they say you're on the coast of Australia.

Botany Bay is unlike many conventional bays which are on the coastline
and part of the sea. You're right that these types of bays are part of
the sea and ocean, and other times they are part of a river, but
botany bay is really a river nor sea, if anything Botany Bay sounds
much more like an Esturary. https://en.wikipedia.org/wiki/Estuary

On 27 March 2017 at 22:46, Christoph Hormann  wrote:
> On Monday 27 March 2017, Andrew Harvey wrote:
>>
>> What water body is Botany Bay
>> https://en.wikipedia.org/wiki/Botany_Bay part of?
>>
>> I don't think it's right too tag the inside of the bay as coastline.
>> "A coastline or a seashore is the area where land meets the sea or
>> ocean" the inside of the bay isn't the sea, hence the water/land
>> boundary isn't the coastline.
>
> I have had this discussion countless times in other cases and Botany Bay
> is not even a borderline case.
>
> It is a bay of the Tasman Sea/Pacific Ocean.  Ecologically it is a fully
> maritime waterbody.
>
> The only alternative would be to consider it the lowest part of the
> Georges River which would be an extreme stretch considering the size of
> the bay and its connection to the sea compared to the discharge of the
> river.
>
> More elaborate discussion of the matter can be found on the wiki:
>
> http://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
>
> As said a bay is not a separate waterbody in OSM so if you consider
> something a bay you need to decide what it is a bay of.  Tagging
> natural=water + water=bay is always factually wrong (and is also only
> used about 80 times globally).
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Andrew Harvey]

On 27 March 2017 at 21:35, Martin Koppenhoefer  wrote:
> as there's the coastline as well, it shouldn't produce any problem to remove
> natural=water from the bay. We generally don't add natural=water to the sea:
> https://www.openstreetmap.org/way/148455492#map=13/-33.9809/151.2086
> because they're dealt with by the coastline rendering.

The problem is this bay, is not part of the sea or the ocean.

See https://snag.gy/h51wM0.jpg. The blue area is Botany Bay, the red
is the coastline, and the yellow is the sea and ocean.

The coastline shouldn't go on the inside of the bay, as it's not the
coast. Shoreline yes, but the coastline is only on the coast in red.

Outside Botany Bay you have the Tasman Sea.

On 27 March 2017 at 21:51, Christoph Hormann  wrote:
> Bays are by definition parts of waterbodies and not independent
> waterbodies so they should not be tagged natural=water.  The waterbody
> they are part of should of course be tagged either natural=water or be
> outside the coastline if it is a maritime bay (as in this case as
> tagged by https://www.openstreetmap.org/changeset/46829336).

What water body is Botany Bay https://en.wikipedia.org/wiki/Botany_Bay part of?

I don't think it's right too tag the inside of the bay as coastline.
"A coastline or a seashore is the area where land meets the sea or
ocean" the inside of the bay isn't the sea, hence the water/land
boundary isn't the coastline.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Christoph Hormann]

On Monday 27 March 2017, Andrew Harvey wrote:
> The wiki for natural=bay says "Since bays are generally part of a
> larger waterbody, either a lake or the ocean, they should not be
> rendered in solid color indicating water themselves."
>
> This creates a conflict with a recent change to Botany Bay
> https://www.openstreetmap.org/relation/1214649 in
> https://www.openstreetmap.org/changeset/47138016.
>
> It was changed from natural=water, water=bay to natural=bay. However
> it most definitely should be rendered as water, contrary to the
> advice on the wiki.

Bays are by definition parts of waterbodies and not independent 
waterbodies so they should not be tagged natural=water.  The waterbody 
they are part of should of course be tagged either natural=water or be 
outside the coastline if it is a maritime bay (as in this case as 
tagged by https://www.openstreetmap.org/changeset/46829336).

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] natural=bay on areas

[Martin Koppenhoefer]

2017-03-27 12:29 GMT+02:00 Andrew Harvey :

>
> What should we do to fix this? Change the wiki to note that it should
> be rendered as water and fix renders?




as there's the coastline as well, it shouldn't produce any problem to
remove natural=water from the bay. We generally don't add natural=water to
the sea:
https://www.openstreetmap.org/way/148455492#map=13/-33.9809/151.2086
because they're dealt with by the coastline rendering.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] natural=bay on areas

[Andrew Harvey]

The wiki for natural=bay says "Since bays are generally part of a
larger waterbody, either a lake or the ocean, they should not be
rendered in solid color indicating water themselves."

This creates a conflict with a recent change to Botany Bay
https://www.openstreetmap.org/relation/1214649 in
https://www.openstreetmap.org/changeset/47138016.

It was changed from natural=water, water=bay to natural=bay. However
it most definitely should be rendered as water, contrary to the advice
on the wiki.

What should we do to fix this? Change the wiki to note that it should
be rendered as water and fix renders?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging