Re: [Tagging] natural=bay on areas

[Juan Pablo Tolosa Sanzana]

No, I just tagged the edge of the bay as natural=coastline because this 
is the top of the tidal range. Even being more rigorous the 
natural=coastline must be shifted far away towards west of current 
position. The lower part of Georges River is a typical ria: an 
unglaciated valley submerged into the seawater.



El 28/03/17 a las 09:47, Andrew Harvey escribió:

Initially I was concerned that by changing the tagging from
natural=water, water=bay to natural=bay that the whole bay would be
rendered as land since that's what the wiki suggests. I now see that
the same user changed the edges of the bay to be natural=coastline to
prevent this.

I'm agree now that it makes sense for the wiki to not recommend
filling bays as water since a bays is either part of the ocean or part
of some other waterbody like a river, lake, reservoir   etc.). A
natural=bay as an area can share a common boundary with the riverbank
like http://www.openstreetmap.org/way/483211748.

I'm not convinced that the inside here should be tagged as
natural=coastline, as it simply doesn't match the description of what
a coastline is. I think the solution here is to include botany bay and
other bays here as part of a waterbody.

On 28 March 2017 at 00:28, 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.

I think it's a grey area, it's not completely like a river, nor that
of the sea. But in this case, I'm not sure, what information do you
have that confirms this?


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.

That's exactly what botany bay is, a 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.

I don't have a problem with waterway=riverbank, as many parts of the
shoreline here are closer to a riverbank than a coastline. That's
probably the best solution here.


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

Thanks for that link!

On 28 March 2017 at 06:48, Juan Pablo Tolosa Sanzana
 wrote:

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

The wiki says "The natural=coastline tag is used to mark the mean high
water spring line along the coastline at the edge of the sea." The
last part is key. The tidal limit is way upstream at
http://www.openstreetmap.org/search?query=-33.9252261917%2C%20150.9283593270#map=15/-33.9252/150.9284
but since the coastline tag is only marking high water mark on the
coast (the boundary between sea and land), it shouldn't be used there.


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

So you're saying that anything below the tidal limit is 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.

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

What's the verifiable thing on the ground which backs up
natural=coastline on the inside of the bay(s)?


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 

Re: [Tagging] Stećci - Bosnian medieval tombstones

[Kevin Kenny]

A tomb without a body, built to commemorate dead whose remains lie
elsewhere, is a 'cenotaph'.

There's an earlier, inconclusive, thread on the topic:

https://lists.openstreetmap.org/pipermail/tagging/2016-September/030196.html


On Tue, Mar 28, 2017 at 5:28 PM, Michal Fabík  wrote:
> Hi,
> some time ago, I was wondering what would be the proper way to tag a stećak
> (plural form stećci), a large monolithic tombstone, often with carved
> inscriptions and/or ornaments, found in Bosnia and neighbouring countries
> (https://en.wikipedia.org/wiki/Ste%C4%87ak).
>
> They are usually the shape of a large coffin (though other shapes exist
> too), but they are solid stone, unlike sarcophagi, which really _are_
> coffins, i.e. hollow. They are usually found in groups from a few up to a
> few hundred. The groups of stećci are locally known as necropolises, though
> they don't quite fit the Wiki's definition of a necropolis - "a large
> ancient cemetery with elaborate tomb monuments" - they are not necessarily
> large, they aren't really ancient (they're medieval) and they're hardly
> elaborate monuments - it's just biggish stone blocks strewn randomly on a
> meadow.
>
> Normally, it would probably be enough to tag the necropolis as a whole
> (probably as some sort of a historic=archaeological_site) but like I said,
> sometimes they are isolated and sometimes they have been moved to a another
> location altogether. Furthermore, there are efforts to catalogue them and
> decipher/translate the inscriptions carved into some of them, so it can
> definitely be of interest to some people to know where exactly a particular
> stećak is located.
>
> They are usually described as tombstones though I'm not 100% sure if all of
> them are tombstones, there might be some that served some other
> (ceremonial?) purpose rather that marking an actual grave, but I might be
> wrong. Then there are some that used to mark a grave but were moved to a
> different location (there are some on display in front of a museum in
> Sarajevo and some other places) so they should be tagged as stand-alone
> objects, not as features of graves. The graves themselves aren't
> significant, to my knowledge - most of them are nameless, they aren't
> normally researched/exhumed etc.
>
> I've started a thread on the Bosnian forum
> (https://forum.openstreetmap.org/viewtopic.php?id=56800, in Serbo-Croatian)
> but I only got one answer since the Bosnian community isn't exactly active,
> so I thought I'd ask what you guys think, even though some of you might not
> be familiar with the subject.
>
> So far, I have a couple of ideas in mind:
>
> historic=rune_stone + historic:civilization=*
>
> + both are established tags
> + to a layperson it gives a pretty good idea what to expect
> - they are not rune stones
> - there is no consensus as to what civilization created them, unless we use
> something very generic like "Bosnian_pre-islamic" or similar
>
>
> historic=tombstone + tombstone=stećak
>
> + probably the most accurate
> - not well established (just one occurrence of historic=tombstone according
> to taginfo.osm.org)
> - not sure whether all of them are tombstones
>
> historic=stećak
>
> + straightforward and accurate
> - not established at all
> - hardly anybody knows what a stećak is IRL
> - contains a non-ASCII character, some people might not be bothered to spell
> it properly
>
> historic=stecak
>
> + more user friendly than the above
> - "wrong" spelling - might confuse users who speak the local language, i.e.
> the ones most likely to map them
>
>
> So, any suggestions?
>
> Best regards,
>
> --
> Michal
>
> ___
> 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?

[Kevin Kenny]

On Tue, Mar 28, 2017 at 7:31 PM, Greg Troxel  wrote:
> This is definitely messy.  Legally, in Massachusetts we have cities and
> towns, both admin_level=8; they are the same thing, but (slightly
> oversimplifying in a way that doesn't matter for this dicussion)
> governed by city council vs town meeting.
>
> But, administrative boundaries and the human geography notion of a
> settlement hierarchy are really totally separate things.  One is about
> borders, and the other is about concentrations of population and a
> shared sense of place.  Yes, the human geography notion is influenced by
> borders; El Paso and Juarez are surely considered separate settlements.
> In a strong sense they actually are different places.
>
> This is further complicated because in many areas every bit of land is
> built up with housing, except where it can't be (wetlands, etc.).  So
> the old notion of a village with a few bouses, and then miles of farms,
> and then the next village, doesn't really fit.  But if you adjust that
> to be a village center with a church or shops, and then miles of just
> houses, it pretty much works.
>
> In the US, there is also the notion of place names for areas that used
> to be villages that mattered, even though these days you can hardly tell
> except to notice a few old houses close together.
>
> While the center of a political entity usually qualifies as a populated
> place (to use the GNIS term) or settlement (to use the human geography
> term), the defined center is usually not the centroid.  So I think it
> makes sense to both define the boundary and the center.  That should be
> sort of a relation, and the point tag should also have a settlement tag
> in addition to being noted as the center of the admin_level entity.
>
> There are towns near me which have an admin_level=8 boundary, and also
> have "South Foo", "North Foo", "Foo", and "West Foo" villages.
> Originally these were clusters of houses.  Then the railroad came sort
> of close, and then the sense of center moved closer to the station.  Now
> the railroad is less important and the sense of center has moved in some
> cases closer to a highway junction with lots of shops.  Sometimes the
> old town centers are really in the exact same place as in 1750.
>
> As for whether there should be polygons for the settlement objects, I
> tend to avoid that, because it's really hard to say what's in the
> village vs near it.   Just ask 50 people in Cambridge, MA whether some
> particular building is "in" Harvard Square.
>
> My overall summary is that boundaries and settlements are different,
> we should tag both, and we should not blur them.

I tag boundaries when there are boundaries. In many places in suburban
New York, the hamlets (not self-governing in any way) have well known
boundaries, and the locals can tell you with some consistency who does
and does not live in the named community.

New York's settlement hierarchy is very messy indeed, and indeed
not quite hierarchical.

Fort Montgomery is one of these. It stops at the parks, the river, the
village of Highland Falls, and the West Point reservation.

A node for the 'center' isn't a bad idea, and for Fort Montgomery, the human
'center' of the settlement is the couple of blocks of Route 9W that have
the post office, the fire station and the school.

Can you give me an example in OSM of the type of relation you have in mind,
so that I could ape it? If such a relation is described on the Wiki, my
Google-fu is failing me.

Kevin

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

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

[Greg Troxel]

Martin Koppenhoefer  writes:

> 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 be fine for changing place=locality to mean:

  a name for a particular location, generally known to the inhabitants
  of surrounding areas, and whose naming significant is other than as a
  name for a population center, such that one of the settlement
  hierarchy terms is not appropriate

more or less.

Here's a place=locality.  A few people live nearby, but that's not
relevant to how people think of the place.  It's an intersection on a
major road, and the gas station (petrol filling station :-) there has
been there since before you were born, and it's "Tracey's".  So pretty
much everyone, including radio station traffic reports, calls it
Tracey's Corner.  If the gas station were to close, people would say
"turn where Tracey's used to be" for at least 20 years.  I have tagged
it as place=locality.

  https://www.openstreetmap.org/node/2448006677

Another example is

  https://www.openstreetmap.org/node/2448006676

again, people live near there, but that's not the point.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Greg Troxel]

Martin Koppenhoefer  writes:

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

This is definitely messy.  Legally, in Massachusetts we have cities and
towns, both admin_level=8; they are the same thing, but (slightly
oversimplifying in a way that doesn't matter for this dicussion)
governed by city council vs town meeting.

But, administrative boundaries and the human geography notion of a
settlement hierarchy are really totally separate things.  One is about
borders, and the other is about concentrations of population and a
shared sense of place.  Yes, the human geography notion is influenced by
borders; El Paso and Juarez are surely considered separate settlements.
In a strong sense they actually are different places.

This is further complicated because in many areas every bit of land is
built up with housing, except where it can't be (wetlands, etc.).  So
the old notion of a village with a few bouses, and then miles of farms,
and then the next village, doesn't really fit.  But if you adjust that
to be a village center with a church or shops, and then miles of just
houses, it pretty much works.

In the US, there is also the notion of place names for areas that used
to be villages that mattered, even though these days you can hardly tell
except to notice a few old houses close together.

While the center of a political entity usually qualifies as a populated
place (to use the GNIS term) or settlement (to use the human geography
term), the defined center is usually not the centroid.  So I think it
makes sense to both define the boundary and the center.  That should be
sort of a relation, and the point tag should also have a settlement tag
in addition to being noted as the center of the admin_level entity.

There are towns near me which have an admin_level=8 boundary, and also
have "South Foo", "North Foo", "Foo", and "West Foo" villages.
Originally these were clusters of houses.  Then the railroad came sort
of close, and then the sense of center moved closer to the station.  Now
the railroad is less important and the sense of center has moved in some
cases closer to a highway junction with lots of shops.  Sometimes the
old town centers are really in the exact same place as in 1750.

As for whether there should be polygons for the settlement objects, I
tend to avoid that, because it's really hard to say what's in the
village vs near it.   Just ask 50 people in Cambridge, MA whether some
particular building is "in" Harvard Square.

My overall summary is that boundaries and settlements are different,
we should tag both, and we should not blur them.



signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Stećci - Bosnian medieval tombstones

[Martin Koppenhoefer]

sent from a phone

> On 28 Mar 2017, at 23:28, Michal Fabík  wrote:
> 
> historic=tombstone + tombstone=stećak
> 
> + probably the most accurate
> - not well established (just one occurrence of historic=tombstone according 
> to taginfo.osm.org)
> - not sure whether all of them are tombstones


I would probably use this one together with historic:civilization 

Just to mention it: there is also a tomb key, but maybe the Stećci aren't tombs.

for necropolis there is a site_type for archaeological_site

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

[Tagging] Stećci - Bosnian medieval tombstones

[Michal Fabík]

Hi,
some time ago, I was wondering what would be the proper way to tag a 
stećak (plural form stećci), a large monolithic tombstone, often with 
carved inscriptions and/or ornaments, found in Bosnia and neighbouring 
countries (https://en.wikipedia.org/wiki/Ste%C4%87ak).


They are usually the shape of a large coffin (though other shapes exist 
too), but they are solid stone, unlike sarcophagi, which really _are_ 
coffins, i.e. hollow. They are usually found in groups from a few up to 
a few hundred. The groups of stećci are locally known as necropolises, 
though they don't quite fit the Wiki's definition of a necropolis - "a 
large ancient cemetery with elaborate tomb monuments" - they are not 
necessarily large, they aren't really ancient (they're medieval) and 
they're hardly elaborate monuments - it's just biggish stone blocks 
strewn randomly on a meadow.


Normally, it would probably be enough to tag the necropolis as a whole 
(probably as some sort of a historic=archaeological_site) but like I 
said, sometimes they are isolated and sometimes they have been moved to 
a another location altogether. Furthermore, there are efforts to 
catalogue them and decipher/translate the inscriptions carved into some 
of them, so it can definitely be of interest to some people to know 
where exactly a particular stećak is located.


They are usually described as tombstones though I'm not 100% sure if all 
of them are tombstones, there might be some that served some other 
(ceremonial?) purpose rather that marking an actual grave, but I might 
be wrong. Then there are some that used to mark a grave but were moved 
to a different location (there are some on display in front of a museum 
in Sarajevo and some other places) so they should be tagged as 
stand-alone objects, not as features of graves. The graves themselves 
aren't significant, to my knowledge - most of them are nameless, they 
aren't normally researched/exhumed etc.


I've started a thread on the Bosnian forum 
(https://forum.openstreetmap.org/viewtopic.php?id=56800, in 
Serbo-Croatian) but I only got one answer since the Bosnian community 
isn't exactly active, so I thought I'd ask what you guys think, even 
though some of you might not be familiar with the subject.


So far, I have a couple of ideas in mind:

historic=rune_stone + historic:civilization=*

+ both are established tags
+ to a layperson it gives a pretty good idea what to expect
- they are not rune stones
- there is no consensus as to what civilization created them, unless we 
use something very generic like "Bosnian_pre-islamic" or similar



historic=tombstone + tombstone=stećak

+ probably the most accurate
- not well established (just one occurrence of historic=tombstone 
according to taginfo.osm.org)

- not sure whether all of them are tombstones

historic=stećak

+ straightforward and accurate
- not established at all
- hardly anybody knows what a stećak is IRL
- contains a non-ASCII character, some people might not be bothered to 
spell it properly


historic=stecak

+ more user friendly than the above
- "wrong" spelling - might confuse users who speak the local language, 
i.e. the ones most likely to map them



So, any suggestions?

Best regards,

--
Michal

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

[Tagging] Pennsylvania colored Interstate detour routes

[Albert Pundt]

Is there an established way of mapping detour routes such as Pennsylvania's
colored Interstate detours, as seen in this picture
? I
would think it would be as simple as using route relations with
route=detour, ref=Green/Blue/Orange/etc, and detour=I 81/I 78/etc, but
before I go and add these I want to know whether these should be mapped at
all, and if so, what standard practice is.

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

Re: [Tagging] natural=bay on areas

[Christoph Hormann]

On Tuesday 28 March 2017, Andrew Harvey wrote:
> >
> > A waterbody where plant and animal life matches or is close to that
> > of the sea rather to that of a river or lake.
>
> I think it's a grey area, it's not completely like a river, nor that
> of the sea. But in this case, I'm not sure, what information do you
> have that confirms this?

My initial assessment was based on an intuitive look on the water 
balance of the bay - which can be backed up with numbers from here:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.575.3453=rep1=pdf

If you do the math you see that the freshwater inflow is insignificant 
compared to the tidal water exchange.

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

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

Re: [Tagging] natural=bay on areas

[Andrew Harvey]

Initially I was concerned that by changing the tagging from
natural=water, water=bay to natural=bay that the whole bay would be
rendered as land since that's what the wiki suggests. I now see that
the same user changed the edges of the bay to be natural=coastline to
prevent this.

I'm agree now that it makes sense for the wiki to not recommend
filling bays as water since a bays is either part of the ocean or part
of some other waterbody like a river, lake, reservoir   etc.). A
natural=bay as an area can share a common boundary with the riverbank
like http://www.openstreetmap.org/way/483211748.

I'm not convinced that the inside here should be tagged as
natural=coastline, as it simply doesn't match the description of what
a coastline is. I think the solution here is to include botany bay and
other bays here as part of a waterbody.

On 28 March 2017 at 00:28, 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.

I think it's a grey area, it's not completely like a river, nor that
of the sea. But in this case, I'm not sure, what information do you
have that confirms this?

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

That's exactly what botany bay is, a 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.

I don't have a problem with waterway=riverbank, as many parts of the
shoreline here are closer to a riverbank than a coastline. That's
probably the best solution here.

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

Thanks for that link!

On 28 March 2017 at 06:48, Juan Pablo Tolosa Sanzana
 wrote:
> 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

The wiki says "The natural=coastline tag is used to mark the mean high
water spring line along the coastline at the edge of the sea." The
last part is key. The tidal limit is way upstream at
http://www.openstreetmap.org/search?query=-33.9252261917%2C%20150.9283593270#map=15/-33.9252/150.9284
but since the coastline tag is only marking high water mark on the
coast (the boundary between sea and land), it shouldn't be used there.

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

So you're saying that anything below the tidal limit is 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.
>
> This is only a colloquial thing. That lacks of verifiability. For example,
> Dead Sea is not a sea, really is a lake.

What's the verifiable thing on the ground which backs up
natural=coastline on the inside of the bay(s)?

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

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

[Martin Koppenhoefer]

2017-03-28 11:20 GMT+02:00 Rory McCann :

> The "unpopulated place" bit is (IMO) just to separate it from
> town/village/hamlet etc, where you should be able to say "How many
> people live here?". In your examples, the people probably say they live
> in the city, rather than the place.
>


yes, this is exactly how I would read it as well (doesn't make a lot of
sense otherwise), although it is often interpreted differently, that's why
I asked if we could make the locality definition less ambiguous. What is
your stance on this?

There are other toponyms with clear reference to something (maybe now
gone), e.g. a city gate (where the name of the city gate often still exists
for the place, although there are now only few remains of the city walls or
gates, in this case I would prefer adding a more precise class (e.g.
historic=city_gate).

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

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

[Rory McCann]

I would suggest place=locality in this case, and have seen it used for
things like that (e.g. in Dublin, Ireland
https://www.openstreetmap.org/node/11675220 ).

The "unpopulated place" bit is (IMO) just to separate it from
town/village/hamlet etc, where you should be able to say "How many
people live here?". In your examples, the people probably say they live
in the city, rather than the place.

Informal places are fine. They satisfy the "on the ground rule". If you
go to the area, and ask 50 local people "How can I get to $PLACE?"
they'll probably all point you to the same place, ergo, it exists.


On 27.03.2017 18:12, 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?

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

[Marc Gemis]

On Tue, Mar 28, 2017 at 9:05 AM, <0174  wrote:
> Hi Marc,
>
> I sometimes have to change the direction of a way when merging two of them
> and when they are oriented in the opposite directions. I.e. when two parts
> of the same road are mapped and I map the part in between, I merge all of
> them when there's no reason not to. I don't know if it's the best practice,
> but I'm sure I'm not the only one doing that.
>
> Vojta

Vojta,

I think merging ways is no problem for the stop sign. It would even
solve a problem in case there is (or has to be) a stop sign on the
node where the ways get merged.

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

[<0174]

Hi Marc,

I sometimes have to change the direction of a way when merging two of 
them and when they are oriented in the opposite directions. I.e. when 
two parts of the same road are mapped and I map the part in between, I 
merge all of them when there's no reason not to. I don't know if it's 
the best practice, but I'm sure I'm not the only one doing that.


Vojta


Dne 28. 3. 2017 v 8:05 Marc Gemis napsal(a):

What are good reasons to change the direction of a way ? Oneway comes
to mind, but is split way at stop sign, revert one arriving way,
change the oneway tag of tag a realistic scenario ? So you end up with
a oneway way that becomes a two-way road at the stop sign.
Are there other reasons to revert a the direction of part of a way ?

Until now I have not seen any real example from the opponents of the
direction tag on a node that shows the need for a relation because the
direction of the node is ambiguous.
All I have seen is "there is a theoretical possibility that..."

Please prove me wrong and show some real world example where it does not work.
(I do understand the need for a relation in case you have to stop
unless you turn to the right).

m.

On Mon, Mar 27, 2017 at 5:29 PM, Martin Koppenhoefer
 wrote:

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


___
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] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Marc Gemis]

What are good reasons to change the direction of a way ? Oneway comes
to mind, but is split way at stop sign, revert one arriving way,
change the oneway tag of tag a realistic scenario ? So you end up with
a oneway way that becomes a two-way road at the stop sign.
Are there other reasons to revert a the direction of part of a way ?

Until now I have not seen any real example from the opponents of the
direction tag on a node that shows the need for a relation because the
direction of the node is ambiguous.
All I have seen is "there is a theoretical possibility that..."

Please prove me wrong and show some real world example where it does not work.
(I do understand the need for a relation in case you have to stop
unless you turn to the right).

m.

On Mon, Mar 27, 2017 at 5:29 PM, Martin Koppenhoefer
 wrote:
>
> 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
>

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