Re: [Tagging] Feature Proposal - RFC - Tag:traffic_calming=hillocky

2020-12-20 Thread Alan Mackie
On Sun, 20 Dec 2020 at 10:11, Niels Elgaard Larsen  wrote:

> Martin Koppenhoefer:
> >
> >
> > sent from a phone
> >
> >> On 19. Dec 2020, at 23:27, Brian M. Sperlongano 
> wrote:
> >>
> >> 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.
> >
> >
> > I thought they would make people drive slower, while retaining a
> possibility for
> > bicycles to pass in between.
>
> That is what the proposal says. But there is no way a bicycle could pass
> between
> those seen on the proposal page at anything near normal bicycling speed.
>
> If you want to allow bicycle
>
> In Denmark we have a larger version of round speed bumps. Usually only 2
> or three in
> each direction.
>
>
> https://aarhus.lokalavisen.dk/aarhus_midt/2dzeno-Carsten-Hedegaard-Simonsen-kigger-ned-p%C3%A5-vejbump/alternates/LANDSCAPE_640/Carsten%20Hedegaard%20Simonsen%20kigger%20ned%20p%C3%A5%20vejbump
>
> They are named "pukkelbump" which translates as hump bumps.
>
> More informally they are called turtle bumps.
>
> So maybe we should call them hedgehog bumps and turtle bumps.
>
Maybe something a bit less 'literary' such as "=dome_array" or
"=rumble_domes" for the small ones and "=dome_bumps" for the larger
depending on whether you would expect them to alert the driver by vibration
or an abrupt bounce?

>
> > I guess these would be counted in?
> > https://www.durabump.com/ 
> >
> > Cheers Martin
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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] sport=shooting_range vs sport=shooting + leisure=pitch

2020-12-19 Thread Alan Mackie
On Sat, 19 Dec 2020, 15:49 Brian M. Sperlongano, 
wrote:

> 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.
>
The wiki recommends leisure=pitch for archery which also seems ill advised.
If anything it might be considered a danger zone of some  kind.

I think we could do with a tag for these sorts of areas. It would probably
be best if it depreciated leisure=pitch for the areas where you would
expect a javelin, discus, "hammer" or shot put to land too. It may also be
an appropriate supplementary tag for driving ranges.

>
> On Sat, Dec 19, 2020 at 3:35 PM Paul Allen  wrote:
>
>> On Sat, 19 Dec 2020 at 19:47, Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>> Is there some good use for sport=shooting_range?
>>>
>>
>> Not in English as she is spoken.  "Shooting range" is not a sport.
>> "Shooting" is a sport.
>>
>>>
>>> Or is it always preferable to use sport=shooting + leisure=pitch?
>>>
>>
>> That's an improvement.  Not ideal, because it's practised at a
>> range, not on a pitch.  Just because we have other sports that
>> have been shoe-horned into leisure=pitch I don't see a good
>> reason to continue making that error.  A few bad ones,
>> but no good one.
>>
>> --
>> Paul
>>
>> ___
>> 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] Feature Proposal - RFC - barrier:guard_stone

2020-12-08 Thread Alan Mackie
On Tue, 8 Dec 2020 at 17:03, Volker Schmidt  wrote:

> My gard stone example  on a building corne
> is also useful
> for this part of the discussion. I know the place well and I know the local
> amateur history expert, and we talked about this specific stone, and also
> asked about its historic value.
>
I'm sorry, I'm having trouble spotting it at that link, is it by the gate?

> It is anywhere between 100 and a couple of hundred years old. It is on a
> building the walls of which may have many hundreds of years. So it's
> historical and as it's the only guard stone in that part of the city, it's
> most likely also historic, not because in itself it is historic, but it's a
> historical marker, as we are not good at keeping historic buildings of
> minor importance.  The next building down the road, (which BTW may well be
> of Roman origin as it used to lead straight to the historic city center of
> Roman Patavium) was a tavern with several hundred years of confirmed
> history, but was torn down about ten years ago to make place for a new
> private house. So my personal opinion is that it is historic, even though
> most likely 99% of the locals have never noticed it.
>
> On Tue, 8 Dec 2020 at 15:15, Paul Allen  wrote:
>
>> On Tue, 8 Dec 2020 at 09:56, Martin Koppenhoefer 
>> wrote:
>>
>>>
>>> I am not saying that these stones should or not get a historic tag, but
>>> surely it isn’t an argument that one of the OpenStreetMap based maps
>>> highlights things based on a wildcard selection.
>>>
>>
>> Not an argument, merely a piece of evidence to consider.
>>
>>
>>> If this tag would pose a problem for their rendering I am sure they
>>> would adjust the selection rules.
>>>
>>
>> Or perhaps we should not force them to adjust their selection rules by
>> abusing
>> "historic" to mean "old."  We have start_date=* to specify that things
>> are old.
>>
>>>
>>> Regarding “historic means historic as in the battle of Waterloo or the
>>> pyramids of Gizeh”, we have seen from previous discussion that this was a
>>> minority opinion.
>>>
>>
>> An explanation, by one person, of what the wiki page says and the
>> distinction
>> between "historic" and "historical."  Those do not mean the same thinhg,
>> however much you wish them to.
>>
>> On the one hand we have the wiki page, the distinction between
>> "historic" and "historical" and a map with the sole purpose of
>> rendering historic, rather than historical, objects.  On the other
>> hand we have people who insist that "historic" means "historical."
>>
>> Many people see historic as a keyword for objects that typically could be
>>> seen as historic, but then includes any objects of the class, without
>>> further  differentiating them by “historic value”.
>>>
>>
>> Many people do not read the wiki page.  Many people do not understand
>> the distinction between "historic" and "historical."
>>
>>>
>>> We do not have different tags for truly historic wayside shrines or
>>> crosses and others. How many charcoal piles do you expect to be of
>>> exceptional historic value?
>>> https://taginfo.openstreetmap.org/keys/historic#values
>>>
>>
>> I would expect a handful, at most, not the tens of thousands that have
>> been
>> mapped.  Those SHOULD have been mapped with a lifecycle prefix.  But
>> people who don't understand the difference between "historic" and
>> "historical" and don't read the wiki misuse historic=* then document it.
>>
>>>
>>> For guard stones I could imagine using the man_made key as well, but
>>> historic would seem to work because most of these are giving testimony of
>>> former times.
>>>
>>
>> "Historic" does not mean "historical."  Those stones are historical but
>> they are not historic.  If you want to emphasise that they are old,
>> start_date=* is the way to go.
>>
>> --
>> Paul
>>
>> ___
>> 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] Feature Proposal - RFC - barrier:guard_stone

2020-12-07 Thread Alan Mackie
I think the direction tag should be described as optional if the node is on
a building way. From the description given the direction of most of these
will be "away from the building".

On Mon, 7 Dec 2020 at 22:16, Volker Schmidt  wrote:

> Yes, that tag is a good idea.
> But, it is not a barrier on the way, but a single object off the way.
> Normally, but not always they come in pairs, but it does not always come
> in pairs. They are often corner stones.
> When there is a pair, i.e. one on each side, it would make sense to see it
> as a barrier, with maxwidth.
> But if it is on a building corner
> , it is a single
> object, not a barrier at all.
> Needs some thinking.
> Volker
>
>
> On Mon, 7 Dec 2020 at 22:28, Anne-Karoline Distel 
> wrote:
>
>> Hi everyone,
>>
>> mostly for European use (I think), I propose a new node type barrier,
>> namely "guard stone":
>>
>> A guard stone is in most cases a stone built onto or into the corner of a
>> building or wall. They are usually found on either side of an entrance to a
>> laneway or gateway. Guard stones may be put alongside a wall to protect it.
>> Many are historical barriers that kept the wheels of carriages from
>> damaging buildings. Some of them bear survey markers such as benchmarks.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/guard_stone
>>
>> Thanks, have a good time, stay safe.
>> ___
>> 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] Elevated housing estate

2020-11-25 Thread Alan Mackie
This probably isn't too far off from many of the larger man_made=pier
structures in resort towns, although it lacks the water underneath most of
the time. Would man_made=bridge be appropriate for the surrounding area?

I think this is becomming fairly common in some flood prone areas, so
dedicated tagging seems like a good idea, both for the usually dry
situation, and for buildings that sit over water but don't even have
vestigial mooring areas.

The wiki lists building=stilt_house, but this seems overly specific.
Whether a building is tagged as being on stilts should be independent of
building use IMO. Regardless in this case min_level=1 seems about right to
me to denote the absence of a ground floor.

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpier
https://wiki.openstreetmap.org/wiki/Tag:building%3Dstilt_house

-Alan

On Wed, 25 Nov 2020 at 06:34, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> add location=overhead on buildings and other objects?
> https://wiki.openstreetmap.org/wiki/Key:location
>
> https://wiki.openstreetmap.org/wiki/Key:building:min_level
>
> https://wiki.openstreetmap.org/wiki/Key:building:levels#Buildings_with_parts_that_don.27t_start_at_ground_level
> (not sure can it be applied if entire building starts above ground level)
>
> Certainly add also description=* tag with info what is happening here,
> maybe with link to this mailing list thread.
>
>
> Nov 25, 2020, 01:00 by graemefi...@gmail.com:
>
> How do you tag an area, in this case an entire housing estate!, that is
> raised up above ground level?
>
>
> https://www.google.com.au/maps/@-28.065772,153.3799853,3a,15y,117.51h,89.21t/data=!3m6!1e1!3m4!1sN_TJvFHJyLff1E4GmiCSjQ!2e0!7i13312!8i6656?hl=en
> (with the usual not mapping from Google ...)
>
> Just draw the outline of the area & tag it as level=1?
>
> The main entry is via a bridge:
> https://www.google.com.au/maps/@-28.0673717,153.3800556,3a,23.4y,28.84h,87.1t/data=!3m6!1e1!3m4!1sBF_8z5ekricuuEFZnUJioQ!2e0!7i13312!8i6656?hl=en
> ,
> which is ok, but should all the internal roads also be marked as bridges?
>
> Thanks
>
> Graeme
>
>
> ___
> 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] Feature Proposal - Voting - parking=street_side​

2020-11-15 Thread Alan Mackie
Never mind. I've just reread it and it seems I need more coffee.

On Sun, 15 Nov 2020 at 10:05, Alan Mackie  wrote:

> This seems an odd term. To me a side street is one that branches off from
> the main road, not an extra bay off to one side.
>
> Do you have a link to the previous discussion?
>
> On Sat, 14 Nov 2020 at 16:33, Alex  wrote:
>
>> Hey all,
>>
>> voting has started for street_side parking:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
>>
>> We propose to introduce "street_side" as a new value for parking=* and
>> parking:lane=*. It is intended for parking areas/bays, which are directly
>> adjacent to the carriageway of a road (but not lane parking on the
>> carriageway) and can be reached directly from the roadway without having to
>> use an access way. If approved, this tagging could resolve some existing
>> ambiguities in the mapping of such parking facilities (see proposal).
>>
>> Thanks for your previous comments and your future votes.
>>
>> Alex (and Jeroen Hoek, the other author of this proposal)
>> ___
>> 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] Feature Proposal - Voting - parking=street_side​

2020-11-15 Thread Alan Mackie
This seems an odd term. To me a side street is one that branches off from
the main road, not an extra bay off to one side.

Do you have a link to the previous discussion?

On Sat, 14 Nov 2020 at 16:33, Alex  wrote:

> Hey all,
>
> voting has started for street_side parking:
> https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
>
> We propose to introduce "street_side" as a new value for parking=* and
> parking:lane=*. It is intended for parking areas/bays, which are directly
> adjacent to the carriageway of a road (but not lane parking on the
> carriageway) and can be reached directly from the roadway without having to
> use an access way. If approved, this tagging could resolve some existing
> ambiguities in the mapping of such parking facilities (see proposal).
>
> Thanks for your previous comments and your future votes.
>
> Alex (and Jeroen Hoek, the other author of this proposal)
> ___
> 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] Questions about public transport tagging

2020-11-14 Thread Alan Mackie
On Fri, 13 Nov 2020 at 22:54, ipswichmapper--- via Tagging <
tagging@openstreetmap.org> wrote:

> Hello, I have quite a few questions about Public Transport related tagging
> in Openstreetmap.
>
> My first question is about the "interval:conditional" & "opening_hours"
> tag for bus routes. The "Bus Route" page on the OSM wiki mentions this tag,
> but the train route or "public transport" route page does not mention this
> tag at all. So I wanted to ask, is this tag discouraged?
>
> The disadvantage of this tag, obviously, is that it is quite difficult to
> maintain. However, I think it is possible. My method would be to make a
> table which contains all the public transport route relations in an area,
> and add a column for "last checked". This would display the last date that
> this public transport route was checked. Regular mappers can do a check of
> a bunch of public transport routes every few months to see if the
> opening_hours or interval:conditional has changed. (I plan on including
> this on a guide to mapping public transport routes that I will be making).
>
> Here is the table for Ipswich:
>
> https://wiki.openstreetmap.org/wiki/Ipswich#Public_Transport_Version_2
>
> Note currently, this is not formatted how I described. The reason for this
> is because not every bus routes has been added, so instead of having a
> "last checked" column, there are four columns ("interval",
> "interval:conditional", "duration", "opening_hours"). This is because some
> of the unfinished routes still don't have these tags.
>
> Second question is about mapping train route stops. If I understand
> correctly, you are meant to add the platform at which people wait with role
> "platform" as well as the stop position of the train with role "stop".
>
> I see issue with this. Firstly, none of this is clarified on the wiki
> under train routes. Secondly, what if you don't know what platform the
> train will leave from? What if there is no platform? In the UK this isn't a
> problem as all train stations have platforms. However, in other countries,
> in rural areas, train stations may not have any built up platform, you just
> wait by the side of the railway.
>
> Secondly, why do you have to map stops and not platforms? Again, if the
> train goes at different platforms, then the stop position will also be
> different. You may not know what the stop position is, in which case you
> chose a random point on the railroad. Instead, it would be much better if
> you could just mark the "station" as a member of the relation. However,
> there is no "station" role, so adding a station creates a role verification
> problem.
>
> Last question is about "combining intervals". This is something that, if
> needed, can be asked about in another thread (as it needs more discussion).
> In many cases, multiple bus routes go down the same path for a significant
> section of their journey, and split near the end of their journey.  An
> example of this is route 66 & route 66A in Ipswich. [1][2][3]
>
> For most of their journey, these buses have the same route. Combined,
> their interval is "every 20 minutes". The interval of 66A is every hour.
> The 66 has a 20 minute interval, then a 40 minute one, then a 20 min one,
> etc.
>
> If these were mapped separately, you a routing software wouldn't be able
> to compute that the interval is 20 minutes. So how can this be fixed?
>
> The solution I can think of is to map a separate relation called
> ("66/66A") which is the combined route and give it a interval of 20
> minutes. However, I'm pretty sure some tags would be needed to be made for
> this, because otherwise it breaks the ground rule (as there is no bus
> called "66/66A" in real life).
>
> Another interesting idea was suggested in this Reddit post:
>
>
> https://old.reddit.com/r/openstreetmap/comments/jkdsjr/common_area_of_bus_routes/
>
> That is that roads with multiple bus routes can be tagged with the bus
> route, instead of the other way route (to cut down on repetition).
>
> Thanks,
>
> IpswichMapper
>
> [1]: https://www.openstreetmap.org/relation/190701
> [2]: https://www.openstreetmap.org/relation/9984463
> [3]:
> https://www.firstgroup.com/uploads/maps/FEC-Ipswich%20Reds%2066%20-%20Bus%20Times%20from%2025-10-20.pdf
>
>
> I think under PTv2 the point you board/alight is meant to be marked as a
platform even when it's just a pole in muddy ground. I have also seen
recent proponents say that stop positions are not compulsory although I
think on one of the first things I saw on PTv2 was strongly of the view
that mainly using stops over platforms was one of its main advantages.

For the 66/66A question: I think under PTv2 each direction for each variant
is meant to have its own route relation which is then combined into a
route_master relation. I would assume that if you have an interval that
applies across variants you would put that in the route_master rather than
the individual route.

Take what I say with a grain of salt though, while I do 

Re: [Tagging] Proposal to change key:man_made to key:human_made

2020-10-18 Thread Alan Mackie
This proposal requires the retagging of over 3 million objects, breaks
every existing rendering, editor and a huge amount of documentation in
order to replace a term already generally considered gender neutral and
easily found in dictionaries (including bilingual ones) with more awkward
phrasing that doesn't even remove the detested string.

Please don't do this.

On Sun, 18 Oct 2020 at 10:11, Rory McCann  wrote:

> On Thu, 15 Oct 2020, at 2:41 PM, Volker Schmidt wrote:
> > And all this effort achieve what?
>
> The  liberation of all people from from gender roles 
>
>
> ___
> 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] Feature Proposal - RFC - (shop=direct marketing)

2020-10-03 Thread Alan Mackie
This seems to me to be a relative of market stalls. Smaller concerns that
are 'staffed' but usually have very focussed or limited stock. Part way
between a fullblown store and a vending machine, you would not expect to
see the facilities you might get in a "proper" shop or as many payment
means (though this depends on location).

To me these seem distinct enough to permit special tagging. Persistent
vendors within otherwise changing marketplaces might also be worth
highlighting for some users. Dedicated vendor tagging could then be shared
across all locations they (repeatedly) appear?

I think the closest we have for this sort of thing is shop=kiosk or
building=kiosk but this describes the physical setup more than the way
they're run.

On Sat, 3 Oct 2020 at 10:40, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> 3 paź 2020, 02:44 od frede...@remote.org:
>
> Hi,
>
> On 10/2/20 19:56, Wieland Kestler wrote:
>
> I agree absolutely that somone who makes bread by itself and sells that
> in front of its house, we should tag it by shop=bakery. So the grade of
> „selfmadeness“ does not matter.
>
>
> We are not a business directory but a geo database. We map what exists,
> and not (or at least not primarily) what services might be offered. If
> there is a residential house and every now and then the owner puts out a
> table in front and sells bread, then I would say we shouldn't map that
> at all. (Map the house, yes, but not map the fact that a resident bakes
> bread occasionally.) In order to be mapped in OSM, it needs to have a
> physical manifestation - at the very least, a sign, or more desirably
> some structure that can be recognised as a shop even while not in use.
>
> And I would say that it is perfectly fine
> to map shops that are gone while not
> in use.
>
> For example food truck that arrives
> every night at the same location
> (OK, except holidays) seems perfectly
> mappable to me.
>
> Similarly, sellers of vegetables, herbs,
> pottery, baskets and whatever else in
> many cases are present only during day
> and disappear without trace in off hours.
>
> I have no problem with mapping them.
>
> See my street_vendor=yes tag idea to
> indicate this state.
>
> ___
> 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] Linking Sidewalks to Highways Was: Re: "width" on streets: Time for a recommendation

2020-09-18 Thread Alan Mackie
On Fri, 18 Sep 2020 at 21:35, Tobias Knerr  wrote:

> On 17.09.20 02:35, Taskar Center wrote:
> > This is yet another example why "sticking" the sidewalks onto the
> > highway (as a tag) rather than mapping them as separate ways is
> > appearing to be less and less practical. Please see our sidewalk schema
> > proposal
> > 
> > from several years ago.
>
> Your sidewalk proposal unfortunately doesn't really address the crucial
> shortcoming of separately mapped sidewalks: The lack of a reliable
> mechanism for figuring out which section of road a given sidewalk way
> belongs to.
>
> I agree that we should be able to give sidewalks their own geometry, but
> we _also_ need the relationship between sidewalk and road. So far, all
> the proposals attempting to support the former end up sacrificing the
> latter.
>
Was this meant to be one of the purposes of associated street relations?

>
> There have been some promising discussions recently around the
> sidepath_of idea, but that's still just brainstorming. Until a practical
> solution is found and actually used in the database, sidewalk mapping
> will remain a choice between two options that are broken in different ways.
>
I hadn't heard this one. Do you have a link to the discussion? I would
personally prefer sidewalk_of or walkway_of if we were to go this route
though. Sidepath sounds like something that's branching to me.

Both associated street and sidepath_of still have the issue of when you're
allowed to jump from one to the other, kerbs can be stepped over by most,
railing less so (they're often to keep pedestrians out of blindspots). It
must be difficult to tell if a sidewalk is separated specifically because
the transition from one to the other is more thoroughly blocked and not
simply as an added level of detail  with no more than the normal impediment
to foot traffic.  The only thing I've seen discussed that might work for
this was in a talk about way and street areas.

>
> As for the main issue of the thread: I would welcome a clear definition
> for the meaning of width. In my own mapping and when writing the
> relevant code in OSM2World, I have counted sidewalks etc. as part of the
> road's width if they are mapped as tags on the main way. But I would of
> course change that if there finally was a documented and widely
> agreed-upon recommendation. I don't care so much which one it is - but
> we need one.
>
> ___
> 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] "width" on streets: Time for a recommendation

2020-09-17 Thread Alan Mackie
On Thu, 17 Sep 2020, 01:37 Taskar Center,  wrote:

> Hi,
>
> This is yet another example why "sticking" the sidewalks onto the highway
> (as a tag) rather than mapping them as separate ways is appearing to be
> less and less practical. Please see our sidewalk schema proposal
> 
> from several years ago.
>
This is all well and good for roads without tree cover in areas where the
imagery is good. At other times a tag on the road is the best option if you
don't want to just make up geometry.

>
> I think @Mark brings up really relevant width distinctions, and I believe
> that once we agree that sidewalks require their own geometry, we should
> have a similar discussion about the interpretation of width in the
> sidewalks context.
>
> I look at this issue from the perspective of routing. Routers are
> interested in functional width (which would be Mark's 'driven path'
> option). Even with the consideration of transiency of both of the last two
> of Mark's definitions, 'maintained' and 'driven path' width, this is a much
> better approximation for additional considerations than routing- it can be
> an indicator of traffic stress, it can provide information for the 'slow
> streets' movement, it can also provide a means of reconciling improper
> imports that labeled all roads as 'primary' when they should not.
>
> My last comment has to do with the separation of sidewalks from streets-
> in that in many locales the responsibility of street maintenance falls on a
> different entity than sidewalk maintenance (for example, in Seattle, the
> sidewalk is the responsibility of the homeowner, rather than the
> municipality who IS responsible for the street infrastructure). So it is
> actually advantageous to have these mapped as separate entities so we can
> keep track of infrastructure maintenance.
>
> Best regards,
>
> Anat
>
>
>
> Sent from my mobile. Please excuse brevity and typos.
> On Wed, Sep 16, 2020 at 1:23 AM Supaplex  wrote:
>
>> I expect the "width" of a way to be the actual width of the object it
>> represents.
>>
>> It depends on how we define "highway" in the OSM sense. You could also
>> assume that sidewalks etc. are "sticking" on the highway merely for
>> pragmatic reasons. Depending on the point of view, sidewalks and highways
>> represent different entities. (There is no law definition here, I only find
>> a German court decision that deals with street widths and thus means the
>> distance between the curbs, with carriageway and parked vehicles, so as
>> definition 2 above.)
>>
>> But I agree that it would be better to always specify which width is
>> meant exactly when mapping widths on streets (especially to use
>> "width:carriageway" for the rating of traffic suitability). Nevertheless, a
>> default, which meaning of "width" is meant without a prefix/suffix, would
>> still be helpful. Fun Fact: On the wiki highway page - in contrast to what
>> is discussed here - it says since 2012 that "width" means the width of the
>> carriageway (but it does not look like this paragraph has ever been
>> discussed):
>> https://wiki.openstreetmap.org/wiki/Highways#Surface.2C_width_and_lighting
>>
>> Alex
>> ___
>> 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] Addition of highway=emergency_bay and priority_road=yes to Map Features?

2020-09-16 Thread Alan Mackie
On Tue, 15 Sep 2020, 07:52 Joseph Eisenberg, 
wrote:

> Two tags were just added to the list of approved and de-facto highway
> =* tags on Map features:
> highway =emergency_bay
>  and
> priority_road =yes
> .
> Both have mainly been used in Germany and nearby areas of central Europe.
>
> https://wiki.openstreetmap.org/wiki/Key:priority_road
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_bay
>
> I question whether these tags are established enough to merit inclusion on
> the Highway map features page and the main Map Features list. Thoughts?
>

Priority road definitely seems like you'd want it on the map features list
if you're in a country that uses it.

Not sure how common emergency bays are?

>
> - Joseph Eisenberg
> ___
> 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] Benches and hostile architecture

2020-08-24 Thread Alan Mackie
On Mon, 24 Aug 2020, 01:48 Paul Allen,  wrote:

> On Mon, 24 Aug 2020 at 01:27, Martin Koppenhoefer 
> wrote:
>
>>
>> > On 24. Aug 2020, at 01:45, Paul Allen  wrote:
>> >
>> > It's hostile to public urinators.
>>
>> agreed, but isn’t publicly urinating an offense anyway?
>
>
> In most jurisdictions.  So is sleeping on a public bench in many
> jurisdictions.
> Countermeasures are hostile to those who would otherwise commit
> offences.  Which is why the wikipedia article considers uncomfortable
> benches and walls that discourage urination to be hostile architecture.
>
> Speed limits are also hostile to people who like to drive fast for example.
>>
>
> I'm not seriously suggesting we map them this way but speed bumps are
> technically hostile architecture. :)
>
Most I encounter are hostile to the speed you're meant to be going, not
just to people exceeding that speed.

Really quite annoying actually.

>
> --
> Paul
>
> ___
> 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] Canopy Walkways

2020-08-22 Thread Alan Mackie
On Sat, 22 Aug 2020 at 11:11, Jake Edmonds via Tagging <
tagging@openstreetmap.org> wrote:

> Doesn’t bridge:structure refer to the design of the supports? A canopy
> walkway could use of mix of simple-suspension, beam and others not
> currently explained in the wiki (I.e some sort of attachment to trees)
>
Yes, according to the wiki, this is the general configuration of the
structural members.
https://wiki.openstreetmap.org/wiki/Key:bridge:structure

There seems to be some overlap with the values of the bridge key.
https://wiki.openstreetmap.org/wiki/Key:bridge


>
Sent from Jake Edmonds' iPhone
>
> On 22 Aug 2020, at 11:36, Peter Elderson  wrote:
>
> 
> I would say the feature is a kind of highway.
> The construction is bridge, so bridge=yes on the highway.
> The highway is a footway, and this kind of footway is called a canopy
> walkway.
>
> The footway part is kind of redundant, which is probably nice if you
> render all footways, but unnecessary when you render canopy_walkways
> specifically.
>
>
> Best Peter Elderson
>
>
> Op za 22 aug. 2020 om 11:16 schreef Jake Edmonds via Tagging <
> tagging@openstreetmap.org>:
>
>> Should the key be bridge?
>> I feel like canopy walkways are more like bridges than boardwalks.
>>
>> Sent from Jake Edmonds' iPhone
>>
>> On 22 Aug 2020, at 11:08, Alan Mackie  wrote:
>>
>> 
>>
>>
>> On Fri, 21 Aug 2020, 21:46 Martin Koppenhoefer, 
>> wrote:
>>
>>>
>>>
>>> sent from a phone
>>>
>>> > On 21. Aug 2020, at 22:25, Andy Mabbett 
>>> wrote:
>>> >
>>> > "public building" and "trunk highway" are also common terms.
>>> >
>>> > Do we tag
>>> >
>>> >building=public_building
>>> >
>>> > or
>>> >
>>> >highway=trunk_hghway
>>>
>>>
>>> these are different because it would be a literal repetition. What we do
>>> is footway=sidewalk rather than „side“
>>>
>>> If general opinion is towards footway=canopy I could live with it, but
>>> my preference goes to canopy_walkway
>>> I’m not expecting so many that the extra characters will be significant
>>> ;-)
>>>
>>
>> I have had to remind myself several times as this thread has developed
>> that this is not intended as a synonym for breezeway or other covered=yes
>> footways.
>>
>> If the previously suggested =treetop isn't accurate perhaps a more
>> explicit =forest_canopy ?
>>
>>
>>> 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
>>
> ___
> 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] Canopy Walkways

2020-08-22 Thread Alan Mackie
On Fri, 21 Aug 2020, 21:46 Martin Koppenhoefer, 
wrote:

>
>
> sent from a phone
>
> > On 21. Aug 2020, at 22:25, Andy Mabbett 
> wrote:
> >
> > "public building" and "trunk highway" are also common terms.
> >
> > Do we tag
> >
> >building=public_building
> >
> > or
> >
> >highway=trunk_hghway
>
>
> these are different because it would be a literal repetition. What we do
> is footway=sidewalk rather than „side“
>
> If general opinion is towards footway=canopy I could live with it, but my
> preference goes to canopy_walkway
> I’m not expecting so many that the extra characters will be significant ;-)
>

I have had to remind myself several times as this thread has developed that
this is not intended as a synonym for breezeway or other covered=yes
footways.

If the previously suggested =treetop isn't accurate perhaps a more explicit
=forest_canopy ?


> 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


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-15 Thread Alan Mackie
On Sat, 15 Aug 2020 at 18:12, Paul Allen  wrote:

> On Sat, 15 Aug 2020 at 17:05, Steve Doerr  wrote:
>
>> On 12/08/2020 19:27, Paul Allen wrote:
>>
>>
> I would interpret 'Collects', 'Issues', 'Spreads', and possibly 'Sinks' as
>> verbs in the third person singular, rather than plural nouns.
>>
>
> That's a bit of an issue, although I think you've included the kitchen
> sink.
>
> Kitchen sinks are more of an indoor tagging thing. :-P


> It is not unknown in English for verbs to get nouned and nouns to get
> verbed.
> Especially in technical English like mapology.
>
> This might affect how we tag them, as we mainly use nouns and adjectives,
>> I think.
>>
>
> As used by OS, these are nouns.  If we had non-cartographic equivalents in
> British English then maybe we should use those instead.  If we decide that
> we want to tag such things in the first place.
>
> --
> Paul
>
> ___
> 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] Waterway equivalent of noexit=yes?

2020-08-11 Thread Alan Mackie
On Tue, 4 Aug 2020 at 02:05, Graeme Fitzpatrick 
wrote:

>
>
>
> On Tue, 4 Aug 2020 at 07:03, Martin Koppenhoefer 
> wrote:
>
>>
>> > On 3. Aug 2020, at 22:10, Tod Fitch  wrote:
>> >
>> > Looking at wikipedia, it seems that “storm drain” is used in the UK,
>> Canada and the US [1]. And there is an “inlet” [2] associated with it. What
>> are the opinions using:
>> >
>> > storm_drain = inlet
>>
>>
>> I would suggest to use an established key, e.g. man_made
>> value could be storm_drain_inlet although this is not very handy. Maybe
>> water_inlet? drain_inlet?
>>
>
> Or the existing manhole=drain is used ~24000 times
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:manhole%3Ddrain=2013942
>
>
I think there was a general feeling on this list that most of those drains
wouldn't fit a man and so calling them manholes is a bit of a misnomer.

Earlier discussion also branched into talk of entrances to culvert like
structures where the other end was unknown or a difficult to map network.
Drainage ditch running into a sewer type situations. These also don't
resemble manholes in the traditional sense.

If the native speakers think that „storm“ is required, so be it
>>
>
> Not essential for this native speaker :-)
>
> Thanks
>
> Graeme
>
> ___
> 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] Apparent conflicting/redundant access tags

2020-08-07 Thread Alan Mackie
On Fri, 7 Aug 2020 at 07:36, Niels Elgaard Larsen  wrote:

> On Thu, 6 Aug 2020 17:12:48 +1000
> Graeme Fitzpatrick  wrote:
>
> >OK, now you've all got me confused!
> >
> >I always thought that access=yes means that it is open to the general
> >public, while access=no means that it's not open to the public?
>
>
> The issue is that it becomes the default for all other transport mode
> access.
>
> I once had OsmAnd direct me to turn my car right on a very tiny path.
>
> It was tagged as highway=foot,access=yes
>
This sounds like an OsmAnd bug. Paths should not be routable for cars
unless they specifically say car=yes, and maybe not even then.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rio de la Plata edit war

2020-08-05 Thread Alan Mackie
On Wed, 5 Aug 2020 at 01:34,  wrote:

>
>
> - Mensaje original -
> > De: "Joseph Eisenberg" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 16:56:31
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > The graphics in this document are mainly models of current flow, rather
> than
> > actual measurements, but it is mentioned that the average current flow,
> > neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds of
> 5 m/s
> > are routine according to the paper, the currents vary strongly based on
> winds
> > and tides.
> > See for example the figura on pages 26 to 37 which show the modeled
> variation
> > with different wind direction. I don't see a modeling of the affect of
> tides -
> > this appears to be the average current over the tidal cycle? But I admit
> I have
> > not visited this area.
>
> Sure its a model, but the model is validated by drifting bouys, as you can
> check in page 37.
> i just translated here.
> "The drift buoy trajectories launched in the summer of 2003 and reported
> by Piola et al (2003) showed, in consistency with the modeled solutions,
> relatively low average speeds (20-30 cm / s) in the middle part of the
> river and higher speeds in the outer sector, mainly towards the Uruguayan
> coast, where they exceeded 60 cm / s (Fig. 33)."
>
> > My main objection is the inclusion of Bahia Samborombon in the estuary.
> The
> > charts and satellite images show very little influence from river water
> in that
> > area, as well as in the section of coast east of Montevideo.
>
> You are misreading the imagery. What generaly available imagery shows in
> this area is a change of colour, which is dark brown to the NW, and more
> clear to the SE. This is caused for the change of turbidity, located near
> the 5m isobath.
>
> The figures in both the document linked by muralito and the one previously
linked by Andy seem to show that flow outside of the line from Montevideo
to Punta Piedras is largely dominated by wind and ocean conditions and not
by the river flow. Visible sediment in the water was discounted earlier for
defining outer limits as it often persists far into areas clearly
considered ocean (see Christoph's example off the coast of China), but
photos showing the sediment also show it starting to disperse after this
point. Some wind directions seem to dominate the flow even further
upstream.

As this discussion continues I think this looks more and more like a river
that drains into a sheltered bay than one that drains directly into the
ocean.

> – Joseph Eisenberg
>
> > On Tue, Aug 4, 2020 at 12:42 PM < mural...@montevideo.com.uy > wrote:
>
> >> - Mensaje original -
> >> > De: "Kevin Kenny" < kevin.b.ke...@gmail.com >
> >> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org >
> >> > Enviados: Martes, 4 de Agosto 2020 16:28:55
> >> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> >> > On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com >
> >> > wrote:
>
> >> >> These rules would exclude the lower Rio De La Plata and the lower
> part of the
> >> >> mouth of the Saint Lawrence river, as well as other wide estuaries
> where winds
> >> >> and tides have more influence on surface water flow than does the
> discharge of
> >> >> the river. It would not prevent mapping the Hudson mouth at the
> southern tip of
> >> >> Manhattan, because the flow is strong all the way to New York
> Harbor, if I
> >> >> understand correctly.
>
> >> > The Hudson definitely reverses flow. One of its names among the First
> Peoples
> >> > translates to 'the river flows both ways.' The division in the flow
> lies less
> >> > in the fraction of the tidal cycle than the speed of the current. It
> flows
> >> > 'upstream' for half the time, 'downstream' for half, but the
> downstream current
> >> > is considerably swifter.
>
> >> Rio de la Plata would not be excluded, as you can read in the document
> [8] i
> >> linked in my first mail, for example, see some graphics of the flow of
> the
> >> river in page 25.
> >> [8] DINAMA. Salinidad
> >>
> https://www.dinama.gub.uy/oan/documentos/uploads/2016/12/patrones_circulacion.pdf
>
> >> Regaards,
> >> M.
>
> >>
> ---
>
> >> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> >> Informate si aplicás aquí.
>
> >> mvdfactura.uy
>
> >>
> ---
>
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
>
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > 

Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Alan Mackie
On Tue, 4 Aug 2020, 14:19 ,  wrote:

> - Mensaje original -
> > De: "Christoph Hormann" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 9:14:32
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > Almost all of the arguments you bring up here are cultural or political
> > in nature.  Discussing those will lead us nowhere.  Hence my suggestion
> > to you in the other mail to consider this exclusively from the physical
> > geographic perspective.
> >
> > The only point i could identify in your writing that is not
> > cultural/political in nature is the claim that the Rio de la Plata was
> > first mapped 6 years ago when the riverbank polygon was created.  That
> > is not true.  The Rio de la Plata was mapped long before - first
> > significant parts started in 2011 already, by end 2012 the mapping was
> > complete:
> >
> > https://overpass-turbo.eu/s/WK9
> >
> > and it stayed tagged as natural=coastline until you changed that in:
> >
> > https://www.openstreetmap.org/changeset/20290034
> >
> > After that there were countless attempts to move up the coastline
> > closure again - all of which however were soon reverted.
> > https://overpass-turbo.eu/s/WKi
> > --
> > Christoph Hormann
> > http://www.imagico.de/
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> I linked several scientific studies that clearly shows and are verifiable
> geographic evidence that this is not an oceanic coast, its a riverbank and
> should not be tagged as coastline. Not cultural, not politics. I just
> linked the treaties to show that there are no political motivations in my
> thinking, because the political issues were already solved many years ago.
> Anyway, most limits, including natural ones are political facts, agreement
> between nations, also including defacto limits because war is also politics.
> It's only physical geographic perspective, its a riverbank, not an ocean,
> its inner fresh water.
>
> You are mixing things. The coastline is not the river. The waterway=river
> for Rio de la Plata was not mapped until i mapped it in
> https://www.openstreetmap.org/changeset/19137685 in November 2013. That
> is 6 years, and will be 7 years in 3 months. Modify your query to search
> for waterway=river and you will see.
> https://overpass-turbo.eu/s/WKi . And no mapping is ever complete, at
> less here where e.g. new sediment islands keeps appearing, old islands
> increase it size, and nearby islands joins toghether.
>
> I changed the tagging because it was and it is wrong to tag this as
> coastline, it's a riverbank, as i have been saying for years. The coastline
> should be in the line because to the west there are inner waters and to the
> east the ocean.
>
> Regards,
> M.
>
>
>
>
> ---
>
> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> Informate si aplicás aquí.
>
> mvdfactura.uy
>
>
> ---
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


There seems to be confusion here between mapping a feature and having it
named. I suspect too much weight is being given to names generally in this
discussion even if this is not explicitly stated. Something OSM considers a
bay may be called a cove in the name, named tidal "creeks" are mapped as
tidal_channel etc. The name can't be the final arbiter of tagging else in
the extreme case we would be rendering Rio de Janeiro in blue along with a
whole chain of coffeeshops.

In this case it is the physical feature that is in question not the extent
of the area that holds that name. The name can easily be tagged separately
on the agreed political boundary.

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


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-08-02 Thread Alan Mackie
On Sat, 1 Aug 2020 at 20:21, Martin Koppenhoefer 
wrote:

>
> > On 1. Aug 2020, at 17:20, Alan Mackie  wrote:
> >
> > I don't know how I'd map this. Do you have to pass through border
> checkpoints when you enter or leave the area?
>
>
> around here, no, but neither are there border checkpoints at the border of
> the main territory, you just walk there without noticing you are changing
> country (referring to the Vatican City)
>
> In this instance I meant the Ahkwesáhsne / US / Canadian situation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rio de la Plata edit war

2020-08-01 Thread Alan Mackie
On Sat, 1 Aug 2020 at 07:21, Paul Norman via Tagging <
tagging@openstreetmap.org> wrote:

> On 2020-07-31 8:21 a.m., Andy Townsend wrote:
>
> On 26/05/2020 00:20, Alan Mackie wrote:
>
> Has this edit war stabilised?
>
> Apparently it has been blocking coastline updates across the whole world
> for *months *now.
>
> https://osmdata.openstreetmap.de/data/land-polygons.html
> https://github.com/fossgis/osmdata/issues/7
>
> (picking this thread up again because there still hasn't exactly been a
> meeting of minds here)
>
> land polygons have been generated (see
> https://osmdata.openstreetmap.de/data/land-polygons.html ) and
> https://github.com/fossgis/osmdata/issues/7 has been resolved by manually
> "releasing" the coastline.  The current situation in OSM is
> https://overpass-turbo.eu/s/WD8 - at the time of writing this the
> coastline crosses the river north of Buenos Aires.
>
> However, edits are continuing (see
> https://www.openstreetmap.org/changeset/88787419 ).  I'm not convinced
> that moving to one of two extremes, even a small amount at a time, is a
> good idea until there's actually been discussion between the proponents of
> the various positions.
>
> For what it's worth, neither extreme position looks the best answer to me
> - looking at the salinity change between river to ocean at
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716 (see
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716 for
> the key picture) and looking at
> https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests a
> location some way between the two.  Despite the NASA photo it looks like
> there isn't a "step change" in salinity - and of course values will
> fluctuate based on winds and tides etc
>
>
> I live near the coast and have done coastline processing, including a
> great deal worldwide during the redaction.
>
> Salinity and territorial control have seldom been considerations in where
> the break between water mapped as waterway=riverbank and natural=coastline
> that I have seen. The break is chosen as a convenient place for mappers and
> a common view of where the coast of the ocean is, not based on scientific
> salinity criteria. For territorial control, look at all the inlets along
> the BC or Norwegian coasts.
>
Perhaps I am an overly literal follower of the wiki, but I had always
assumed the coastline should continue inland as far as the tide continues
to be noticeable. Mediterranean mapping might be an issue, but elsewhere I
think this is fairly clear?

If the water is fresh or the waterway still appears to be a river, canal
etc, then it seems reasonable that they should also have those tags as
well. The coastline and riverbank tags aren't fighting for a common key, so
it's not a direct tagging conflict.

As for territorial control, there are archipelagic states with territorial
waters despite large gaps between all their islands. I'm not sure why
inlets or bays pose a problem?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-08-01 Thread Alan Mackie
On Fri, 31 Jul 2020 at 19:56, Kevin Kenny  wrote:

> On Thu, Jul 30, 2020 at 5:07 PM Alan Mackie  wrote:
>
>> Many if not most of the entities mentioned in this discussion as being
>> candidates for "admin level above country" do have geographic reach
>> encompassing multiple countries, but are also limited in scope, often
>> severely. To tag such a limited body as fully encompassing a higher admin
>> level seems fundamentally flawed as a concept. If their powers were
>> expanded to have unlimited scope within that geographic area you would
>> effectively have a single larger country. Having an entity grow in scope
>> from "admin levels that includes (largely) independent countries" down to
>> admin level of a country seems counter to the general structure.
>>
>
> The defining test probably has to be the power to engage in foreign
> relations with entities at the same admin_level without deferring to the
> next higher level.
>
> Possibly. My main thrust is that I think the top level, "doesn't formally
have to defer to anyone", should share a common admin_level.

The test as you have stated it fails in federal systems. In the US, at
> least, the plenary power to govern belongs to the States (Or to the People,
> but constitutionally this is enforced only by a requirement that each State
> have a republican form of government.)  The national government has only
> those powers that are delegated to it from the states under the
> Constitution. When it tries to exercise plenary jurisdiction (as, alas,
> we're seeing nowadays!), it tends to unfold as a constitutional crisis.
> The States are above the Federal government, not beneath it.
>
> The reason that this principle is not obvious from abroad is that the
> States have delegated to the Federal government the sole power to engage in
> foreign relations; a State may not engage in diplomacy abroad because the
> States have relinquished that power.  Which is why, when you arrive at JFK,
> you clear US customs and not New York's.
>
> Above/below is often rather fuzzy when talking about systems with
elections. An overwhelming majority of states need to ratify constitutional
amendments for them to become effective, but as states representatives form
the federal legislature that pass them anyway this seems like another path
to the same conclusion (not that requiring multiple paths is a bad thing
when it comes to big decisions). What may be relevant here is that states
that vote against an amendment in congress and refuse to ratify the
amendment when passed would still see powers transferred from them to the
federal government.



> By the way, a 'containment' test fails as well in the US.  While there are
> no municipal governments that cross state lines (there are some
> special-purpose entities that do by the consent of both states and the
> Congress, such as the Port Authority of New York and New Jersey), it's not
> uncommon for a city to lie in more than one county, or a village in more
> than one township.  Having a clean hierarchy of admin_levels just isn't
> important to USAians.
>
> I'm OK with higher admin levels cutting across lower ones or overlapping
when they share jurisdictions. What may be useful is some way of recording
who does what in broad, "visible to the mapper", categories.

And I have Absolutely No Idea what to do with extraterritorial dependencies
> or domestic dependent nations.
>
> Feel free to stop reading here. I'm going off topic.
>
> The nearest problem case to me is Ahkwesáhsne, a territory of
> the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy that straddles
> the US-Canadian border, and whose government is recognized by neither
> state. The political situation there has deteriorated into shootings as
> recently as 1990, and sabre-rattling among US, Canadian and Akwesáhsro:non
> persons as recently as 2009. The disputes usually stem from one or the
> other large nation deciding to deny the Kanien'kehá free pratique to travel
> and trade within their own nation, requiring customs and imposts every time
> the US-Canadian border is crossed.
>
> I don't know how I'd map this. Do you have to pass through border
checkpoints when you enter or leave the area?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Alan Mackie
On Thu, 30 Jul 2020 at 19:59, Phake Nick  wrote:

>
>
> 在 2020年7月31日週五 00:24,Alan Mackie  寫道:
>
>>
>>
>> On Thu, 30 Jul 2020 at 16:38, Martin Koppenhoefer 
>> wrote:
>>
>>> Am Do., 30. Juli 2020 um 17:13 Uhr schrieb Alan Mackie <
>>> aamac...@gmail.com>:
>>>
>>>> This is why I suggested that the more practical solution would probably
>>>> be to re-tag all existing admin_level=2 with admin_level=1 except for the
>>>> EU ones as there are far fewer elements to be updated. Arbitrarily deciding
>>>> that the EU gets its own admin_level not used by other top level entities
>>>> breaks consistency with the rest of the world for the sake of local pride.
>>>>
>>>
>>>
>>> which other top level entities are you getting at? Why should we not tag
>>> these with the same tag?
>>>
>>
>> Other independent nations, this is why I suggested the promotion of all
>> other admin_level=2 if we went this rote
>>
>
> admin_level=1 is by definition higher than national level.
>

According to the wiki, but current practice doesn't really use it for much
beyond historic sites according to previous replies to this thread.  At a
practical level it mostly seems reserved for future use.

I would say a historical example could be German Confederation, before the
> unification of Germany
> Another historical example could be the Communist Bloc, which is larger
> than the Soviet Union.
> It might also be useful to map the limit of power of other countries that
> formally controls a number of tributary, vassal or proxy states beyond its
> own border.
>

For the 'territories formerly known as colonies' that formally remain at
least partly attached to their former ruling states a variety of levels are
currently in use. The self governing ones seem to be tagged as
admin_level=2, others as 3 or 4 depending on how they see themselves. At
least in my non-scientific look at the ones that happened to pop into my
head. These largely seem to have found their own solutions within OSM's
existing tagging structure. Attempting to tag proxy states seems like
taking political stances that OSM has historically tried to stay as far
away from as possible.

Many if not most of the entities mentioned in this discussion as being
candidates for "admin level above country" do have geographic reach
encompassing multiple countries, but are also limited in scope, often
severely. To tag such a limited body as fully encompassing a higher admin
level seems fundamentally flawed as a concept. If their powers were
expanded to have unlimited scope within that geographic area you would
effectively have a single larger country. Having an entity grow in scope
from "admin levels that includes (largely) independent countries" down to
admin level of a country seems counter to the general structure.



___
> 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] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Alan Mackie
On Thu, 30 Jul 2020 at 16:38, Martin Koppenhoefer 
wrote:

> Am Do., 30. Juli 2020 um 17:13 Uhr schrieb Alan Mackie  >:
>
>> This is why I suggested that the more practical solution would probably
>> be to re-tag all existing admin_level=2 with admin_level=1 except for the
>> EU ones as there are far fewer elements to be updated. Arbitrarily deciding
>> that the EU gets its own admin_level not used by other top level entities
>> breaks consistency with the rest of the world for the sake of local pride.
>>
>
>
> which other top level entities are you getting at? Why should we not tag
> these with the same tag?
>

Other independent nations, this is why I suggested the promotion of all
other admin_level=2 if we went this route.


> Actually, admin_level=1 is already quite established, just with a
> different key: heritage=1 (for UN heritage sites)
> https://taginfo.openstreetmap.org/tags/heritage=1#map
>
>
>
>>
>> The EU is not the only entity that has arisen by agreement of neighbours
>> to clump together, in that respect it is only unique in that it is the most
>> populous one that happens to be doing so at this particular point in time.
>>
>
>
> you are of course free to add the past ones in OHM ;-)
>
> I think most of the surviving ones are already in OSM as admin_level=2.

A more radical approach would be to drop admin_level entirely and rely on
the way the relations are nested.  However, I imagine the thought of
processing that would reduce all but the most stoic of data consumers to
tears, not to mention the fragility of mapping this way, the difficulty in
doing so with OSM's typical philosophy of incremental improvement and the
myriad of problems that results when borders are fuzzy and hard to pin
down.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Alan Mackie
On Thu, 30 Jul 2020 at 15:02, Colin Smale  wrote:

> On 2020-07-30 15:05, Alan Mackie wrote:
>
> On Thu, 30 Jul 2020 at 13:35, Colin Smale  wrote:
>
>> On 2020-07-30 14:02, Frederik Ramm wrote:You might not like it, but the
>> EU is already a super-state that acts as one, with a federation of states
>> below. I know the whole idea of a "United States of Europe" and a formal
>> federal constitution is toxic, but basically we are already there. What is
>> left to do is to remove the opt-outs and other exceptional treatment
>> afforded to certain states.
>>
>
> If this is truly the case then we already have a label for this:
> admin_level=2 (but see below).
>
>
> The absolute number of the admin_level is less relevant than the relative
> position in the hierarchy. The level for the EU must be above (i.e.
> numerically lower) than the level of its members. If the EU comes in at
> level 2, then the member states would have to go to level 3 or 4; as many
> countries already use these levels, it could cause an avalanche of changes
> and cause the tagging in Europe to get unacceptably out of step with the
> rest of the world. The EU is a unique construct, so it should not be
> surprising if it needs a unique solution in OSM.
>

This is why I suggested that the more practical solution would probably be
to re-tag all existing admin_level=2 with admin_level=1 except for the EU
ones as there are far fewer elements to be updated. Arbitrarily deciding
that the EU gets its own admin_level not used by other top level entities
breaks consistency with the rest of the world for the sake of local pride.

The EU is not the only entity that has arisen by agreement of neighbours to
clump together, in that respect it is only unique in that it is the most
populous one that happens to be doing so at this particular point in time.
Of course every entity is unique in its own special way, but the uniqueness
of individual trees and mountains doesn't stop us from attempting
consistent tagging.


>
>
> I would prefer to map the EU as a contract than as an administrative
>> boundary. There are many such contracts around the world, where smaller
>> countries pool their defense or other typically national capabilities,
>> and I would not be surprised if there were situations where countries
>> pool their defense with one group, and their currency with another.
>> Mapping these things as "areas on the map" is old-style cartographic
>> thinking. We can do better than that.
>>
>> The EU has laws with direct effect, which override national laws. This
>> pooling of capabilities you refer to would not have any laws of its own -
>> only treaties between countries, which may implement certain measures in
>> their national laws as a consequence. The EU is not like that, it has its
>> own laws, that our representatives get to vote on.
>>
> EU directives generally have to be transposed into national law by all the
> member states. IIRC it is the copy-pasted law that theoretically holds the
> power even though the members have all agreed to run everything through the
> photocopier. Whether this is a tangible thing or just a figleaf is for the
> lawyers to fight over.
>
>
> No, it is extremely clear that some EU directives have direct effect,
> without any action being required from the member states.
>
> https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=LEGISSUM%3Al14547
>

>From the link above: " This principle only relates to certain European
acts. Furthermore, it is subject to several conditions."

So only certain things, the rest continue to behave largely as if the
states had developed them individually.


>
>
>> Even *if* a boundary was mapped, it would probably more pragmatic to map
>> the outer boundary of the Schengen region than the outer boundary of the
>> EU states.
>>
>> The Schengen region is DEFINITELY not an admin boundary. It does not
>> actually exist in a tangible form, only as EU law and treaties of
>> association on paper. It covers only part of the EU, and several non-EU
>> territories.
>>
> I disagree with this, the agents at the border are very tangible.
>
>
> The agents at the border don't work for "Schengen" - they work for their
> national organisations. There is no "Schengen" to employ them. What I meant
> by tangible was some kind of organisation with people and offices. It also
> doesn't have its own rules and regulations - they are now part of the aquis
> communitaire. Changes to "Schengen rules" are just EU law changes like any
> other. Speaking of border agents, it is actually the absence of such agents
> (on the internal borders) that characte

Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Alan Mackie
On Thu, 30 Jul 2020 at 14:33, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 30. Jul 2020, at 14:41, Alan Mackie  wrote:
> >
> > To me pooling resources does not generate a higher level entity, it
> rearranges existing ones. If the EU does become the "final decider" across
> all branches of government, then to me it becomes the admin_level=2 entity
> and the states that form it become "lower level" entities.
>
>
> the final decider across some branches of government can also be a lower
> entity than the country level, eg states or German Bundesländer in federal
> systems.
>

The agreement to leave powers to smaller entities still normally recorded
in law or legal ruling at the "next level up" though?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Alan Mackie
On Thu, 30 Jul 2020 at 13:35, Colin Smale  wrote:

> On 2020-07-30 14:02, Frederik Ramm wrote:
>
> Hi,
>
> On 30.07.20 13:32, Colin Smale wrote:
>
> The EU is «composed-of» whole member states. It has all the attributes
> of a governmental administrative body - with the executive, parliament
> and justicial branches impacting citizens directly.
>
>
> To me as a citizen of a EU country it does not feel like the EU is a
> higher-level administrative body than the country. Yes, countries have
> decided to contractually transfer some rights and responsibilities to
> the EU but that doesn't (in my mind) mean the EU is some form of
> super-state. Quitting the EU if you don't like it is much easier than
> seceding from a country.
>
>
> Ask the Brits how easy it is to leave...
>

I think it's a great deal easier than it would be for e.g. California to
succeed from their union. Easier is not the same as easy.

You might not like it, but the EU is already a super-state that acts as
> one, with a federation of states below. I know the whole idea of a "United
> States of Europe" and a formal federal constitution is toxic, but basically
> we are already there. What is left to do is to remove the opt-outs and
> other exceptional treatment afforded to certain states.
>

If this is truly the case then we already have a label for this:
admin_level=2 (but see below).


> I would prefer to map the EU as a contract than as an administrative
> boundary. There are many such contracts around the world, where smaller
> countries pool their defense or other typically national capabilities,
> and I would not be surprised if there were situations where countries
> pool their defense with one group, and their currency with another.
> Mapping these things as "areas on the map" is old-style cartographic
> thinking. We can do better than that.
>
>
> The EU has laws with direct effect, which override national laws. This
> pooling of capabilities you refer to would not have any laws of its own -
> only treaties between countries, which may implement certain measures in
> their national laws as a consequence. The EU is not like that, it has its
> own laws, that our representatives get to vote on.
>
>
EU directives generally have to be transposed into national law by all the
member states. IIRC it is the copy-pasted law that theoretically holds the
power even though the members have all agreed to run everything through the
photocopier. Whether this is a tangible thing or just a figleaf is for the
lawyers to fight over.


> Even *if* a boundary was mapped, it would probably more pragmatic to map
> the outer boundary of the Schengen region than the outer boundary of the
> EU states.
>
> The Schengen region is DEFINITELY not an admin boundary. It does not
> actually exist in a tangible form, only as EU law and treaties of
> association on paper. It covers only part of the EU, and several non-EU
> territories.
>
>
I disagree with this, the agents at the border are very tangible.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Alan Mackie
On Thu, 30 Jul 2020 at 13:05, Frederik Ramm  wrote:

> Hi,
>
> On 30.07.20 13:32, Colin Smale wrote:
> > The EU is «composed-of» whole member states. It has all the attributes
> > of a governmental administrative body - with the executive, parliament
> > and justicial branches impacting citizens directly.
>
> To me as a citizen of a EU country it does not feel like the EU is a
> higher-level administrative body than the country. Yes, countries have
> decided to contractually transfer some rights and responsibilities to
> the EU but that doesn't (in my mind) mean the EU is some form of
> super-state. Quitting the EU if you don't like it is much easier than
> seceding from a country.
>

To me pooling resources does not generate a higher level entity, it
rearranges existing ones. If the EU does become the "final decider" across
all branches of government, then to me it becomes the admin_level=2 entity
and the states that form it become "lower level" entities. In practical
terms it would probably be easier at that point to give them admin_level=1
and automatically retag all non-EU admin_level=2 entities as admin_level=1
(~250?) rather than running through every admin boundary within the EU and
adding 1 to it (thousands?). After all, in many countries, the admin_levels
are already rather sparse so having a gap between 1 and 3 shouldn't be too
much of an issue.  This doesn't seem like a thing that will need to happen
for another couple of decades if it happens at all.


> I would prefer to map the EU as a contract than as an administrative
> boundary. There are many such contracts around the world, where smaller
> countries pool their defense or other typically national capabilities,
> and I would not be surprised if there were situations where countries
> pool their defense with one group, and their currency with another.
> Mapping these things as "areas on the map" is old-style cartographic
> thinking. We can do better than that.
>
> Even *if* a boundary was mapped, it would probably more pragmatic to map
> the outer boundary of the Schengen region than the outer boundary of the
> EU states.
>

I think it would be useful to have distinct tagging for these types of
agreements, I know of at least one other currency union, and I can imagine
a map of what you need in your wallet might come in handy for travellers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Alan Mackie
IMO the logic behind putting the EU as admin_level=1 would have meant that
the United States of America, the USSR and Australia would have been made
admin_level=1 when they were formed from their preceding entities (if OSM
had existed at those times).

I would suggest that contrary to the preceding thread: if and when the EU
becomes as unified as the above examples it would make more sense to put
the EU as a whole as admin_level=2 and add one to all boundaries of the
states and subareas already mapped within it.

On Thu, 30 Jul 2020 at 10:40, Frederik Ramm  wrote:

> Hi,
>
> On 30.07.20 11:19, Mateusz Konieczny via Tagging wrote:
> > Unlike such objects EU has (AFAIK) well defined border, matching
> > existing administrative boundaries, so problems inherent in
> > mapping fuzzy objects are not present.
>
> I'm not an expert on international treaties but I believe that if France
> bought Alaska from the US tomorrow, then Alaska would become part of the
> EU, without the EU having much of a say in it, isn't that so?
>
> This is of course a very hypothetical example but little swaps of
> un-inhabited land happen between neighbouring countries from time to
> time. The "EU boundary" is the sum of whatever national boundaries its
> member states have. Same with the "Schengen area" which is guarded by
> Frontex which you linked to; it's a construct that is the result of a
> contract but not an administrative area.
>
> > I am not opposing it and it seems defensible.
>
> Anything is, on this mailing list ;)
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Orange County, California Building and Address Import

2020-07-28 Thread Alan Mackie
I thought the thing ESRI recently announced was basically additional layers
within RapiD, but I may be conflating two separate things.

On Tue, 28 Jul 2020 at 15:53, Tod Fitch  wrote:

> I became aware that Orange County, California has released building
> outline and address data to public domain [1] and started prep work for
> import to OSM. In reading through the import guidelines [2] it seemed the
> process was:
>
> 1. Create a workflow (but don’t do any actual importing at this stage).
> 2. Document the workflow in both a dedicated wiki page and in the import
> catalog [3]
> 3. Announce to the tagging list and the list for the area, in this case
> talk-us, the proposed import.
> 4. Once comments on the proposed import have been addressed, commence the
> import (documenting progress along the way).
>
> To that end, I have reviewed the data. Processed sample portions to the
> point just short of uploading to OSM to verify I think the workflow is okay.
>
> This is where I am at present:
>
> 1. I’ve reviewed the data and decided that a rather slow manual process is
> needed because of the low quality of the building outlines.
> 2. I’ve created a workflow and tested to the point where I think it will
> result in a good quality import.
> 3. I’ve created a GitHub project containing the description and scripts I
> am using [4].
> 4. I started to create a wiki page containing the same description but
> found an existing import page for the same data [5]
>
> At this point I am paused and looking for guidance as there is another
> import proposed for this data. I don’t see evidence that this other import
> has actually started.
>
> I have added a discussion item to that import page expressing my concern
> about building footprint quality and the steps that will be needed to bring
> it up to standard and given my GitHub project page link.
>
> But I am confused.
>
> I thought that imports needed to be added to the catalog. This import is
> not in the table at present.
>
> I thought that import specific user IDs were required. This import pages
> states “The plan is for most OSM mappers to use their standard OSM
> accounts if they are editing with RapiD and JOSM editors. . .”
>
> I thought that imports needed to be announced in this import list. Looking
> though the archives [6] for the last few months, I don’t see it.
>
> So, do I continue with my import plan with the next step being creating a
> new wiki page for it? Or do I wait for ERSI to do an import then verify the
> quality? I don’t see a way to participate with ERSI listed in the import
> wiki page they’ve created.
>
> Thanks for the guidance!
>
> Tod Fitch
>
> [1]
> https://data-ocpw.opendata.arcgis.com/datasets/8db4b58e6bbf4f6cac676f477348be48_0
> [2] https://wiki.openstreetmap.org/wiki/Import/Guidelines
> [3] https://wiki.openstreetmap.org/wiki/Import/Catalogue
> [4] https://github.com/n76/OSM_OC_Buildings
> [5]
> https://wiki.openstreetmap.org/wiki/Import/Orange_County,_California_Buildings
> [6] https://lists.openstreetmap.org/pipermail/imports/
>
> ___
> 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] Waterway equivalent of noexit=yes?

2020-07-24 Thread Alan Mackie
This is specifically about how to label the end point where the waterway
doesn't drain into another waterbody, not how to label an intermittent
stream in general.

On Fri, 24 Jul 2020, 07:05 Graeme Fitzpatrick, 
wrote:

>
>
>
> On Thu, 23 Jul 2020 at 01:27, Tod Fitch  wrote:
>
>>
>> We are still left with the situation where an ephemeral waterway fans out
>> over the desert and disappears. We need some sort of tagging to indicate
>> this is not a mistake and I’ve not seen a tag or value come up in this
>> discussion that has any existing use or consensus in the list.
>>
>
> It would appear that =stream + intermittent=yes is the best option?
>
> https://wiki.openstreetmap.org/wiki/Key:intermittent
>
> Wadi https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwadi was
> previously used but deprecated in favour of intermittent
>
> Drystream could be an option?
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddrystream, but now
> also discouraged.
>
> Ephemeral was also proposed but apparently hasn't gone any further?
> https://wiki.openstreetmap.org/wiki/Proposed_features/ephemeral
>
> Don't know how any of them would go with OSMOSE though?
>
> Thanks
>
> Graeme
>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Alan Mackie
On Thu, 23 Jul 2020 at 21:18, Mike Thompson  wrote:

>
>
> On Thu, Jul 23, 2020 at 1:36 PM Jmapb  wrote:
> > As I see it, having bicycle=no imply permission to push a dismounted
> bicycle violates the principle of least surprise because it's inconsistent
> with other *=no access tags. I wouldn't presume I could push my car along a
> motor_vehicle=no way, or dismount my horse and lead it along a horse=no way.
> bicycle=no is a strict "no", it is just that it means "no bicycling" or
> "no bicycle riding."
>



> Perhaps it is unfortunate that for modes of transportation we picked nouns
> rather than verbs (e.g. foot vs. walking), but that is what it is by long
> tradition.  A similar thing applies to horse=no.  There are roads (some of
> the US Interstates) where you can not ride your horse, but you can load
> your horse into a trailer, hook the trailer up to your truck, and drive
> with your horse on those same roads.
>

And now I have the perverse desire to suggest that if bicycle=no prevent
(bi)cycling we should use bicycling=no to prohibit the bicycle itself. But
that would be as terrible as I am currently finding it funny.

I suggest that if what is prohibited is pushing the bicycle, then we make
> an explicit tag for that bicycle_pushing=no. The same with regards to
> carrying the bicycle. If possession is prohibited all together, then
> bicycle_possession=no.
>
> This sounds wordy but reasonable. Keep the mode prohibition on a separate
tag to the item prohibition.  Yes it is another tag for routers to deal
with, but it doesn't break the one they already look at.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Alan Mackie
Do we have any tagging for areas where e.g. open alcohol containers are
prohibited,  where firearms are specially prohibited* or disallows
possession of a recording device or camera? A separate 'specific item
banned' tag is starting to sound like it would avoid further muddying the
transport mode tags.

*in jurisdictions that permit them in the first place of course.

On Thu, 23 Jul 2020 at 07:57, Mark Wagner  wrote:

> On Wed, 22 Jul 2020 22:49:47 +0200
> bkil  wrote:
>
> > Am I understanding correctly that this is what the wilderness rules
> > would like to achieve?
> > vehicle=no + scooter=prohibited + bicycle=prohibited +
> > moped=prohibited + unicycle=prohibited + hand_cart=prohibited +
> > wheeled_luggage=prohibited
> >
> > I think if we concentrated on this case, it would be better to invent
> > a specific access value to convey that they don't want to see you be
> > in possession of anything that could leave a track in normal use
> > (access=legged). When you go out with something like this in the
> > wild, they could rightly infer that you would want to ride it when
> > the park rangers are not looking. Not sure about the extent of such
> > restriction, but it might also make sense to put it onto the natural
> > area instead of each and every individual path of it.
> >
> > Am I right in that they still allow riding on the back of animals
> > (like an elephant, buffalo, yak, camel, donkey or horse) or machinery
> > that mimic limbic locomotion (like AlphaDog
> > )?
>
> In a US Wilderness Area, any form of mechanical transport is
> prohibited, so the AlphaDog is out.  Animal transportation is regulated
> on a case-by-case (and area-by-area) basis, but in general, horses,
> llamas, and donkeys are allowed, while camels and yaks are a "maybe".
> Elephants would almost certainly be prohibited because of their
> potential to damage the "wilderness character" of the area.
>
> --
> Mark
>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Alan Mackie
On Wed, 22 Jul 2020 at 14:22, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> 22 Jul 2020, 14:24 by pla16...@gmail.com:
>
> On Wed, 22 Jul 2020 at 13:22, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
> bicycle=explicit_no sounds to me like "there is an explicit sign
> forbidding this",
>
>
> Indeed.
>
>
> not "bicycle vehicle itself is prohibited, not just cycling".
>
>
> That sounds like bicycle=prohibited. :)
>
> Maybe prohibited_item?
>

Would bicycle=contraband work? It's stretching the definition a little, but
does have the emphasis on 'prohibited item' rather than 'prohibited mode'.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-07-20 Thread Alan Mackie
On Mon, 20 Jul 2020 at 11:28, Paul Allen  wrote:

> On Mon, 20 Jul 2020 at 10:59, Volker Schmidt  wrote:
>
>> manhole=drain is widely used in OSM for water drainage grids, that are
>> not suitable for people to entr - se the photo on the wikipage
>> 
>>
>
> People have used manhole=drain for that purpose and the wikipage
> for manhole=drain documents that use.  However, that photo appears
> to be of a UK storm drain which is not a manhole by my definition
> (too small for entry by a person) or by the wiki's definition for
> Key:manhole which states "Hole with a cover that allows access to
> an underground service location, just large enough for a human to climb
> through."
>
> In my opinion we should deprecate manhole=drain except where
> it really is large enough for access by a person.  We need a
> better tag.  Well, two tags.  One for storm drains and one
> for sinks that are too small to merit natural=sinkhole with
> any of the current sinkhole=* types.  Oh, and a tag for
> spreads, too.
>
> --
> Paul
>

I think we also need one for "entrances" to pipes/tunnels of unknown extent
where the entrance is by horizontal movement of the water rather than by
falling into a hole. The presence/absence of gratings or mesh may be useful
for these too.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-07-18 Thread Alan Mackie
On Sat, 18 Jul 2020 at 19:09, Paul Allen  wrote:

> On Sat, 18 Jul 2020 at 18:53, Tod Fitch  wrote:
>
>>
>> What I’d like is one or two tags to indicate that all visible indications
>> of a water way ends at this point and that the QA tools should not flag
>> them as errors to be fixed.
>>
>
> One of the things we need is an anti-spring.  Marked on Ordnance Survey
> maps
> as a sink.  We have natural=sinkhole but that seems only to apply to a
> large
> hole and/or depression.
>

The closest I can find on the wiki is manhole=drain? sinkhole=ponor seems
to be for natural-looking versions.

For the delta like regions if these tend to just peter out, some sort of
intermittent water area may be better. Like for an infiltration basin, but
natural. Then again, maybe Osmose shouldn't complain about the abrupt end
of an intermittent waterway unless another one starts nearby?

https://wiki.openstreetmap.org/wiki/Tag:manhole%3Ddrain

https://wiki.openstreetmap.org/wiki/Tag:sinkhole%3Dponor



> I can see that the underground storm drain system may need a different
>> indication as the waterway does continue, it is just not visible where.
>>
>
> It's a culvert, if you know its route.  Otherwise it's anybody's guess
> where it goes
> and what happens to it.
>

There are wiki pages for tunnel=flooded (doesn't ring true for a sewer) and
man_made=pipeline + location = underground (also seems inappropriate).

There is also an old proposal for water networks here:
https://wiki.openstreetmap.org/wiki/Proposed_features/water_network#Wastewater_network_.28sewer.29

I'd be tempted to just put culvert tagging on the node and add a barrier
tag for any gratings. I'm sure that will also annoy the validators, but it
should at least indicate to other mappers that it goes somewhere.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to map terrace buildings with names

2020-07-07 Thread Alan Mackie
On Tue, 7 Jul 2020 at 21:50, Skyler Hawthorne  wrote:

> On Tue, 2020-07-07 at 21:00 +0100, Paul Allen wrote:
>
> > On Tue, 7 Jul 2020 at 20:32, Skyler Hawthorne 
> > wrote:
> > > Maybe it wasn't clear, but what I'm suggesting isn't to remove the
> > > suggestion of tagging as individual building=houses, but adding
> > > another
> > > section that says something to the effect of "for cases where the
> > > terraced houses are part of a large building, and not simply
> > > attached
> > > houses, another approach could be this way..."
> >
> > That depends what you mean by "large building."  The original
> > British terminology, and the current American terminology, is
> > "row house."  Houses with common side walls built in a row.
> >
> > If you are suggesting using terrace to describe a topology that
> > isn't actually a row of houses, that would be very confusing.
> >
> > --
> > Paul
>
> On Tue, 2020-07-07 at 15:47 -0400, Matthew Woehlke wrote:
> >
> > This seems like a really grey area. See also notes below.
> >
> > A good question might be, do they have separate *entrances*? If not
> > (e.g. some condominiums), then they should possibly be tagged as
> > apartments. In this case, it appears the entrances are separate.
> >
> > Personally, if it's possible to determine the boundaries between
> > properties, my inclination would be to model them as separate
> > buildings.
> > (It's somewhat worth noting that townhouses are *owned*, at least in
> > part, separately.) Property records can probably help with this. You
> > can
> > probably get shapefiles of the property boundaries from the county.
> > (Conversely, if they *aren't* separate lots, that would be an
> > argument
> > for modeling them as single buildings.)
> >
>
> They each have separate entrances, and house numbers. Public tax lot
> records confirm that they are indeed separate lots.
>
> But I'm starting to think that maybe this issue is coming down to
> semantics. What exactly do we mean when we say "building" vs "house"?
> The personal interpretation I am working off of is that a "building" is
> the complete physical structure, whereas a "house" in the context of
> the existing OSM tags (although maybe not in the general sense of the
> word) is the dwelling in which someone lives.
>
> So with this interpretation, a terrace is one building that contains
> multiple houses (or dwellings, or whatever). To me, it doesn't make
> sense to say that each house is a separate building.
>
> Admittedly, I just map as a hobby, and I am not anything like a subject
> matter expert, so I do not claim that these interpretations are the
> "correct" ones. But I would be interested to hear if anyone else has
> more knowledge or a different interpretation.
>
> --
> Skyler
>
>
> To my mind in terraced houses the party walls between are essentially
exterior walls that happen to be shared and are probably all structural,
whereas in apartment buildings or condos they are less substantial. In some
areas there seems to be a tendency for these walls to poke above the
roofline, presumably as a firebreak. I think they also tend not to have any
sort of association that looks after the building as a whole for terraced
houses, they are essentially completely separate properties that are joined
together (not that this is surveyable).

There are instances where I have seen parts of a row of terraced houses
pulled down leaving one of the old dividing walls as the new end wall
without there being much in the way of visible new structure to make it
sound again. There may just be some patched holes where beams were removed
etc. On the other hand I would not expect to see the demolition of half of
a "building" without some significant rework.

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


Re: [Tagging] "Feature Proposal - RFC - Qanat"

2020-06-21 Thread Alan Mackie
On Sun, 21 Jun 2020 at 15:00, ael  wrote:

> On Sun, Jun 21, 2020 at 01:41:53PM +0100, Steve Doerr wrote:
> > For what it's worth, two points:
> >
> > 1. The Oxford English Dictionary spells this word as kanat.
> >
> > 2. It doesn't sound like anything we would refer to as a canal in
> English:
> > canals are for transportation (goods or humans) and are designed to
> > accommodate boats (even if no longer used in that way).
> >
> +1.  I have noticed this misuse of "canal" before.
>
> I would tend to agree with this but Lexico (by Oxford) also mentions
"convey water for irrigation", so it's probably not entirely fair to say
they are (or were) meant to be navigable.

https://www.lexico.com/definition/canal

Maybe it is a mistake to limit aqueduct entirely to historic objects. Could
we tag them as waterway=aqueduct and aqueduct=qanat ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Adding mapillary tags to every building

2020-06-19 Thread Alan Mackie
On Fri, 19 Jun 2020 at 17:07, Cj Malone <
me-osm-tagg...@keepawayfromfire.co.uk> wrote:

> It's in Facebooks interest to have OSM be the best it possibly can.
> Facebook doesn't want to be dependant on Google for map data, so they
> are going to try and commoditise map data to improve competition.
>
> Google just released Google Maps SDK for Unity, an API for app
> developers to make Pokemon Go type games. OSM can't compete on that
> kind of ease of development. I think Facebook will come out with
> similar APIs to try and stop Google growing it's map data market share.
>
>
> How does Google's Unity SDK compare to the one that Mapbox offers?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-11 Thread Alan Mackie
On Thu, 11 Jun 2020 at 04:25, Graeme Fitzpatrick 
wrote:

>
>
> On Thu, 11 Jun 2020 at 11:31, Paul Allen  wrote:
>
>> On Thu, 11 Jun 2020 at 02:10, Mike Thompson  wrote:
>>
>>> I don't think anyone is saying that tracks can't have additional uses,
>>> just that one of those uses has to be forestry, agriculture (and maybe
>>> mineral extraction/energy).
>>>
>>
>> They HAVE to have one of those uses?  Really?  No exceptions.
>>
>
> Sorry, I could probably worded that better, but a number of our tracks
> follow power line / gas pipeline easements, but are open to the public to
> use.
>
> Others branch off from a road, through the bush down to a fishing /
> swimming spot on the creek / river / dam.
>
> Others cross through private property, but are an accepted way to get from
> here to there, & are in some cases even named, despite being 4wd only &
> track type 3 - 5!
>
> I suppose "farm" tracks that go around the various paddocks on a property
> could be called agricultural, but they are usually just a means of getting
> to those areas, & are frequently open to the public on a "permissive" basis.
>
> So I'm sorry, but I have to emphasise that all tracks are not for forestry
> or agricultural use only.
>
> +10

I grew up in an area with little to no agriculture and where the logging
dried up decades ago, but it still has tracks. They aren't just leftovers.

FWIW my go-to online dictionary defines [1] a track as:

> 1. A rough path or road, typically one beaten by use rather than
> constructed.
> *‘follow the track to the farm’*
> 1.1  A prepared course or circuit for athletes, horses, motor vehicles,
> bicycles, or dogs to race on.
> *‘a Formula One Grand Prix track’*
>
-
>
> 1.2  mass noun The sport of running on a track.
> *‘the four running disciplines of track, road, country, and fell’*
>

(Before quickly diverging into entirely non-transport related items)

As they claim to be "powered by Oxford" and giving a UK dictionary I think
it's fair to say this definition is for British English.

I really don't understand the OSM community's fondness for elevating
agriculture and forestry above all else for this tag, but if we want to
exclude things that are clearly tracks from our highway=track definition,
please suggest an alternate road classification we can use for:
Ways for two track vehicles that

   1. tend to go around rather than through obstacles
   2. are minimally improved as the need arises
   3. aren't proper service roads
   4. don't form a proper part of the road network
   5. in many cases you'd be wary of using for low clearance vehicles.

 I think most people would take one look at them and say "that's a track",
and barring evidence that would lead to 'service=driveway', I would tend to
agree.

Remember that in much of the world we haven't been maintaining these ways
for the last thousand years as countries have risen and fallen and haven't
yet fully integrated every possible route into the proper road network. I
do not want to find myself in a situation where the average router tries to
send me down vastly inferior ways because OSM refuses to call these what
they are.


[1]: https://www.lexico.com/definition/track
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-06-08 Thread Alan Mackie
On Mon, 8 Jun 2020 at 14:07, Paul Allen  wrote:

>
> The whole world is dangerous.  Just label the entire planet as a hazard.
>
> Last I heard it was "mostly harmless".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-06-08 Thread Alan Mackie
On Mon, 8 Jun 2020 at 01:27, Jarek Piórkowski  wrote:

> On Sun, 7 Jun 2020 at 19:17, Warin <61sundow...@gmail.com> wrote:
> > As for tagging 'dangerous areas' .. areas that pose danger such as some
> favelas cannot be tagged in OSM. I see the same logic applied to dangerous
> areas caused by wildlife.
>
> Big difficulty in defining where to place cut-off for dangerous and
> when an area is dangerous... Ultimately most of the world has some
> dangerous wildlife. If very unlucky you could be gored by a boar
> within city limits of Berlin. Bears are semi-regularly found in some
> suburbs of Vancouver. Where would you draw the line?
>
>
Signs are often posted for dangerous wildlife or trail conditions. I think
the signs themselves would be more than welcome in OSM.

I don't know how this would be incorporated into a wider "area" type
structure though. I imagine the boundaries of these areas are quite
nebulous?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] Should we map things that do not exist?

2020-06-07 Thread Alan Mackie
On Sun, 7 Jun 2020 at 22:34, Martin Koppenhoefer 
wrote:

>
> this is about a different topic: projects that have been started but have
> never been completed and the fragments are now either:
> repurposed
> or
> left to decay
> or
> waiting to be completed
>
> I would be quite interested in standardised tagging for roads where
construction started, but never finished and have been (mostly) abandoned
for years (existing as mostly usable tracks).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Highway mistagging ... again

2020-05-30 Thread Alan Mackie
On Sat, 30 May 2020 at 16:55, Kevin Kenny  wrote:

> As far as I can tell, `tracktype` is mostly intended for surface
> firmness: how likely are you to sink if you drive it in wet weather?
> If I'm not doing a field survey in mud season, it's hard to tell.
> Everythiing from grade3 to grade5 will have vegetation growing on it.
> In the ruts, I'll see at least some hard material because the soil
> around here is stony.  (Around here, too, grade1 is likely to be at
> least `highway=service`, since nobody troubles to seal a track that's
> used just for tractors or logging trucks.) I also don't see a lot of
> ways with `tracktype` in my part of the world, so I don't have good
> local examples to go on.
>
The main benefit I see to it is the presence or absence of ruts. These may
act as an additional impediment to turning, cause ground clearance issues
or collect water. Softness seems to be covered by detailed enough surface
tags. A tag for the profile of the cross-section could supersede it
entirely if surface and smoothness are also included. For paved roads it
might also include values for whether there is a (noticeable) crown or
banking, or if the sides slope down to a central drain as is reasonably
common in setts.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Highway mistagging ... again

2020-05-30 Thread Alan Mackie
On Sat, 30 May 2020 at 18:23, Florian Lohoff  wrote:

>
> On Fri, May 29, 2020 at 04:10:42PM -0600, Mike Thompson wrote:
> > I know we just had a similar discussion, but I am discovering more and
> more
> > cases where mappers have changed every dirt road they can find to
> > "highway=track".  For example, it looks like all of the dirt roads in the
>
> I am fighting for this now 10+ years and its a hard fight. I live in the
> countryside and regularly people show up, retagging everything to track.
> Most of the times its people living far away in pretty urban areas.
>
> The open issues for rendering surface and/or smoothness on OSM-carto have
stalled, but it might help fight this. It is often used as a proxy for
"four wheel drive preferred". I am guilty of this myself in tagging
semi-abandoned construction.


> I found the description of what a track is good. All osm wiki articles
> for highways classes miss the point "When does this _not_ apply".
>
> For tracks i have simple criteria when it cant be a track:
>
> - residential buildings (or used for reaching them)
> - (school) buses
> - garbage collection trucks
> - postal services
>
> If anything is seen on that road it cant be a track. A track is defined
> as a road for exclusive or mostly agricultural usage. So as soon as
> there is a single residential building the amount of traffic for that
> building outweights the amount of agricultural traffic by orders.
>
> So a farms driveway is also not a track.
>
> Those last three seem a good inclusion in the rather wordy  highway=track
versus other classes of highway=*

section on the wiki. Your blunter title might help too. Most
tracktype=grade1 are probably highly suspicious.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Highway mistagging ... again

2020-05-30 Thread Alan Mackie
I think part of the problem with the highway=track description is that even
when you are there on the ground it isn't always clear what it's being used
for. They are often two ruts in the ground disappearing of into the
distance with little else to go on. If you then look at aerial imagery you
may see that is goes to a single house and re-tag as driveway or that it
serves multiple buildings and guess at whether the buildings lean towards
highway=residential, highway=service or highway=unclassified. It's easy to
say "primarily agricultural or forestry" but this is often rather difficult
to verify.

There is then a separate problem in that OSM-carto, the default 'check that
it worked' renderer, doesn't render road surfaces or tracktypes for
anything other than tracks. This discourages the 'proper' tagging for those
who want to tell at a glance how likely they are to get their car stuck or
how likely it is that they will be able to do a three point turn if there
are obstructions.

Tangentially, I have always found the tracktypes a little difficult to
apply if you don't have the type of soil depicted in the examples. Some
ground tends to get "lumpier" rather than softer if you keep using it
without improvement.

On Sat, 30 May 2020 at 01:33, Andrew Harvey 
wrote:

> I think the wiki already does a good job at communicating this.
>
> iD already goes a step too far calling these "unmaintained track roads"
> but if anything that would have prevented people tagging as highway=track
> just because it is maintained, so not a factor in this case.
>
> I think the default renderer does play a role with some people might be
> tagging for the renderer, but nothing can be done about that from the
> tagging perspective.
>
> I see someone has left a changeset comment, that's the right thing to do,
> it gives the person who made this change a chance to come back either a
> counter point on why they really should be highway=track, or a chance for
> them to learn about their mistake and improve so they don't make it again.
> If you don't hear back from the comment, you could just go ahead and fix
> them back to residential if that's how you know they should be.
>
> On Sat, 30 May 2020 at 08:12, Mike Thompson  wrote:
>
>> I know we just had a similar discussion, but I am discovering more and
>> more cases where mappers have changed every dirt road they can find to
>> "highway=track".  For example, it looks like all of the dirt roads in the
>> area of this way: https://www.openstreetmap.org/way/17051445 have been
>> changed to "highway=track", when at least most of them should be
>> "highway=residential."  What can be done to better communicate that OSM has
>> a functional highway classification system (I did leave a change set
>> comment, but I doubt it will do any good)?
>>
>> Mike
>> ___
>> 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] Rio de la Plata edit war

2020-05-25 Thread Alan Mackie
Has this edit war stabilised?

Apparently it has been blocking coastline updates across the whole world
for *months *now.

https://osmdata.openstreetmap.de/data/land-polygons.html
https://github.com/fossgis/osmdata/issues/7


On Mon, 13 Jan 2020 at 11:40, Christoph Hormann  wrote:

> On Monday 13 January 2020, Frederik Ramm wrote:
> >
> > According to Wikipedia, the International Hydrographic Organization
> > defines the eastern boundary of the Río de la Plata as "a line
> > joining Punta del Este, Uruguay and Cabo San Antonio, Argentina",
> > which is what has been the case in OSM until now:
>
> That is a straw man argument that has been floated already at the very
> beginning when a riverbank polygon was first created for that (which
> was later than when the Río de la Plata was originally mapped by the
> way - just to clarify that).
>
> The IHO specifies an (obviously subjective and non-verifiable) set of
> limits of *oceans and seas*.  If anyone wants to use this as an
> argument that would make the Río de la Plata a marginal sea of the
> Atlantic Ocean and therefore to be placed outside the coastline.  So
> using the IHO as a source (in lieu of the verifiable geography in a
> Wikipedia-like fashion so to speak) kind of defeats the basic argument
> for the Río de la Plata to not be a maritime waterbody.
>
> > This current representation in OSM leads to a few strange situations
> > especially in toolchains/map styles that use different colours for
> > inland water and oceans, or that draw sea depths, or just highlight
> > the coastline. Buenos Aires, according to OSM, is currently not a
> > coastal city.
>
> The main reason why the current mapping is vigorously maintained by some
> local mappers is political in nature.  Argentina and Uruguay want to
> claim this area as internal waters (and the administrative boundaries
> are mapped accordingly) but not every other nation accepts this claim.
> Presenting the Río de la Plata as a non-maritime waterbody in as many
> maps and data sets as possible would support such claim.
>
> My own solution as a data user to this has been to simply maintain a
> coastline cheatfile which marks this as a special case and moves the
> Río de la Plata polygon into the ocean polygon data.  This is
> unfortunate but way simpler than trying to fight against a widespread
> politically motivated conviction.  See also:
>
> https://wiki.openstreetmap.org/wiki/Tag:maritime=yes
>
> > I'm not so clear about how to interpret the wiki page myself when it
> > comes to river mouths. There's a clarifying proposal here
> > https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River
> >_transit_placement but this is still at the proposal stage.
>
> The IMO logical approach to placing the closing segment of the coastline
> at a river mouth according to the spirit of the OpenStreetMap project
> is to place it where for the verifiable view of humans the maritime
> domain ends and the riverine domain starts.  This is largely an
> ecological question.  Coastline and riverbanks are physical geography
> features so their position is to be defined by physically observable
> characteristics rather than politically defined limits.  Like so often
> (for example in case of the line between scrubland and woodland) this
> is often not a clearly visible sharp line but a transit.  There are
> however clearly observable limits to the extent of this transit.  The
> proposal cited tries to specify those.
>
> Back when i drafted the proposal there was very little interest in the
> subject except by those who were opposed to it for political reasons.
> Therefore i did not pursue it further.  But anyone is welcome to take
> it up again.
>
> --
> 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] Route names that aren’t names

2020-03-30 Thread Alan Mackie
On Sun, 29 Mar 2020 at 12:33, Paul Allen  wrote:

> On Sun, 29 Mar 2020 at 10:42, Sarah Hoffmann  wrote:
>
>> * section_name (section? stage? leg?)
>>
>
> Segment?  Just a thought.
>
> Might be a bit too much baggage in that term?
https://wiki.openstreetmap.org/wiki/Segment
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Criticism of PTv2

2020-03-10 Thread Alan Mackie
On Tue, 10 Mar 2020 at 20:54, Phake Nick  wrote:

> On 2020-03-10 Tue 19:47, Dave F via Tagging 
> wrote:
>
>> > A platform is a platform, a perfectly flat bit of sidewalk isn't.
>>
>> +1
>>
>> DaveF
>>
>
> In the sense of bus, sidewalk could be a platform because they are raised
> from the driving road surface. You can google "bus platform" and see many
> example of the word being used in real world.
>
>>
I'll buy into that for the ones with the special raised kerb that some
buses can get more or less level to, and for specially constructed ones in
bus stations, but not for an unmodified area. I suspect in many regions
it's barely higher than the road camber and despite the difficulty for
wheelchairs etc, wouldn't normally be seen as "raised" by your hypothetical
"average person".

For me that Google search returns images that tend towards the "more
heavily modified" end of the spectrum, but who knows what sort of
personalisation they're running.

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-10 Thread Alan Mackie
On Tue, 10 Mar 2020 at 07:55, John Doe  wrote:

> > A new housing estate with two connections to the existing road system
> could cause the bus to be re-routed.
>
> Sounds a little odd - would a router really route a bus on a
> highway=residential or highway=service?
>

I should hope so, many bus stops are on residential roads.


> But, be that as it may, your response helped me see two things -
> 1. It will be helpful to have a route visualizer in editors that can
> preempt ambiguities.
> 2. Hail and ride routes longer than last-mile services really do suffer
> under this schema.
>
> > Which is fine if they're alternative ways of mapping bus routes. But the
> proposers seem to want to make this the one and only way of doing things.
>
> I reiterate that I initially wanted it to be just that - an additional way
> to map. But I also don't want to see it go the way of PTv2, where some
> consumers still don't support the new schema even after 8 years of being
> asked to. And I definitely don't want ways in routes where there's no need
> for them, but someone decides to add them 'for completeness' (for instance,
> so many appear to have difficulty in comprehending that stop positions in
> PTv2 are optional 臘♀️), oblivious to the maintenance issues.
>

If you think that "after 8 years" people have serious misunderstandings
about PTv2 and "difficulty in comprehending" it, then please improve the
documentation on the wiki. The burden in written communication does not lie
solely on the reader.

Whenever I have tried to use PTv2 'in anger' I have found the wiki
confusing and seriously lacking in a summary page. The page that comes
closest to an overview for the buses seems to be the generic buses
 page, but even it has
diversions into clicking certain buttons and "dragged and dropped" objects
(In what editor?) and seems quite rambly. I think the authors suspect the
meaning isn't getting through from their frequent use of bold phrases, but
this doesn't seem to have helped with readability. It also takes the
unusual step of saying that the PTv1 roles are "invalid"  rather than
'depreciated' as tends to be the phrasing when tagging styles move on which
seems deliberately inflammatory given that from the responses here v2 is
still somewhat controversial.

The main route=bus page implies that ALL roles are equally optional
although presumably you have to have some instances of something or you end
up with an empty relation. If anything this page has the opposite problem
to the buses page, it is brief enough that it might serve as a reminder to
those already familiar with the schemes, but provides little to no
clarification for those that aren't.

Which gives me the following idea - would it help you if only routes with
> hail_and_ride=yes were permitted to have ways? For selective hail and ride,
> we can use the via roles as currently written in the proposal. That lets
> you use ways where they are most important (longer, completely hail and
> ride routes), and keeps them out of where they're a nuisance.
>
> (Routes with hail_and_ride=yes could still opt to omit ways and use
> points, which would be better for shorter routes.)
>
This seems reasonable, but explicitly banning ways seems to be a serious
break in backward compatibility. In that cases I would suggest dropping the
PTv3 moniker and referring to this as an abbreviated or condensed route
relation. PT-zip, simPT? If the original idea was to be a simplification
of  PTv2 tagging then this might not be a bad idea anyway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Criticism of PTv2 (was: Feature Proposal - RFC - Public Transport v3)

2020-03-09 Thread Alan Mackie
On Mon, 9 Mar 2020 at 11:30, John Doe  wrote:

>
> This is quite off-topic, but I can't bear to read more completely
> unfounded criticism of PTv2.
>
> I hereby declare that I find the old tags to be a complete abomination (Is
> it on the way? Is it beside the way? Is it a stop, a platform, a halt, a
> station? Why is a platform or a bus stop a railway or a highway?), and PTv2
> tags to be very consistent and comprehensible in comparison. Indeed, this
> thread has motivated me to stop using legacy tags entirely - to hell with
> Carto and other legacy consumers.
>

So it's better to label them all as platforms? I can't see any raised area
in a typical bus stop:
https://www.mapillary.com/app/?lat=53.470542=-2.23758900071=17=sHRXz6nnNKdV1u_AFXAjJw=OpenStreetMap=photo

Why would we tag it as if it looks like this?
https://www.mapillary.com/app/?lat=53.48198622803868=-2.2391616517737676=17=OpenStreetMap=-yZ4kkeVica0Kcmnd-TotA=photo

The section for buses on the main public transport page says: "If there is
no real platform ... the location of the bus stop sign ...  gets ...
public_transport=platform. " I.E. If there is no platform, make one up. How
is that more logical than highway=bus_stop for "there is a bus stop here"?

As for 'why is  a bus stop a highway' do you also suggest we scrap the
tagging for traffic lights, road signs, crosswalks etc. etc?

If tram stops (as described on the wiki) are accessible from both sides and
> it makes sense to put them on the way, then PTv2 is very much justified in
> creating an umbrella tag for stops which are placed on the way. I don't
> understand why the critics of PTv2 seem to think stop positions are such a
> big deal - they are optional!
>

They are largely imaginary for most types of transport. Most public
transport experiences centre around where the people stand not when the
driver slams on the brakes.


> Platforms are where passengers wait.
> Stations are places with many platforms.
> Stop positions are where vehicles stop - an optional alternative to using
> platforms, included for backward-compatibility.
> And the feature is not confounded with the vehicle that serves it, nor the
> infrastructure provided. A platform is a platform regardless of shelter,
> bench, or tactile paving.
>

A platform is a platform, a perfectly flat bit of sidewalk isn't.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread Alan Mackie
Ptv2 uses a different relation for every possible direction, variant and
whim and rolls them up into a routemaster relation. So you can
theoretically check whether each bit is continuous.

On Mon, 9 Mar 2020, 17:09 Dave F via Tagging, 
wrote:

> On 09/03/2020 13:21, Jarek Piórkowski wrote:
> >
> > PTv2 is fine for people who want to handle routes that have variants
> > and branches and who want computer validators to be able to spot
> > potential errors in these branches.
>
> I'm intrigued: What Ptv2 tags enable those?
>
>
> DaveF
>
> ___
> 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] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread Alan Mackie
On Sun, 8 Mar 2020, 13:48 Dave F via Tagging, 
wrote:

> This proposal by Stereo is nothing really new.  Just a alternative to
> routing which has been around since relations were introduced.
> Definitely not 'PTv3'. The 'via' option appears almost as difficult to
> maintain as including ways.
>
>
> On 08/03/2020 01:41, John Doe wrote:
>
>
> >
> > That would be tempting, because it would mean a lot less work for us in
> the short term. However, I'm afraid of ending up like PTv2 -
> > 1. It 'does not deprecate the old tags', use of the new tags is
> 'recommended but not mandatory'...whatever that means.
> It means PTv2 tags aren't required as there are existing tags performing
> the same job.
> > 2. People with a preference for the old tags see that as an excuse to
> keep using them
>
> No. They are preferred because they simple to comprehend, accurate &
> abundant.
> > 3. Consumers see that as an excuse to not support the new schema, even
> after 8 years of people requesting it -
> https://github.com/gravitystorm/openstreetmap-carto/issues/311
> PTv2 
> isn't supported because it's not abundant (people get bored of
> adding them after a couple weeks)
>
> > 4. People who want to use the new tags have to use _both_ sets of tags
> 臘♀️
> No they don't. They can use just the original tags. PTv2 tags are pure
> duplication.
> > 5. Both sets of tags have to be documented, making the documentation
> more verbose than it might be.
> > They should coexist...for a transitional phase. But it has to be just
> that - a _transition_, not a permanent inconsistent mess.
>
> The original tags are here to stay because they work. PTv2 is a
> *separate*, *independent* scarcer schema running in parallel that adds
> nothing over existing tags.
>
> It is only PTv2 which is the mess. Even those who conceived it are
> confused by it.
>
> DaveF
>

 Whenever I have considered adding things in a ptv2 compatible way I have
ended up confused and reverted to a simple highway=bus_stop. Ptv2  seems to
want imaginary unverifiable stop points and for you to add signs on poles
as "platforms" for reasons I could never fathom. Then of course even the
simplest route actually has to be two or more routes for some reason. All
of these seemed to have documentation spread across several different wiki
pages with no clear relationship to each other.

The new proposal seems to be an attempt to get back to the clarity of the
original system while throwing the baby away with the bathwater. In theory
a router could reconstruct a route from points, if it's simple enough, but
if we are going to do that then we may as well drop the route relation
completely and just put the list of services on the stop nodes where most
jurisdictions have them signposted. After all, we have just massively
increased the amount of data crunching by any consumer anyway, they may as
well start that process by doing a search for local refs and build their
own stop lists.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Unremovable bollards

2020-02-16 Thread Alan Mackie
On Sun, 16 Feb 2020 at 20:54, ET Commands  wrote:

>
> > Message: 1
> > Date: Sun, 16 Feb 2020 11:22:11 +0100
> > From: François Lacombe 
> > To: "Tag discussion, strategy and related tools"
> >   
> > Subject: Re: [Tagging] Unremovable bollards
> >
> >
> > Hi all,
> >
> > My 2 cts : key actuator and especially actuator=hydraulic_cyclinder or
> > pneumatic_cylinder values are suitable for movable bollards (pchtt
> > noise when bollards go up and down means actuator=pneumatic_cylinder for
> > instance)
> > https://wiki.openstreetmap.org/wiki/Key:actuator
> >
> > bollard=unremovable for fixed bollards sounds good to me.
> >
> > All the best
> >
> > François
>
>
> My spelling check does not like "unremovable" but instead suggests
> "irremovable."  However, if I want to be nit-picky, all bollards are
> ultimately removable, so maybe more appropriate values would be
> "retractable" and "non-retractable."
>
> Mark
>

Which brings us back to "fixed" as a nice simple description? Not easily
removable, not folding, not lifting. Fixed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] From the Australian fires (still burning unfortunately) how to map burnt areas

2020-01-26 Thread Alan Mackie
There are some tags documented on the Russian wiki page for key:wood [1]
that describe various types of damage to wooded areas, one of which is
wood:damage=burnt. I don't think it's been used much outside of Russia, but
it seems fairly reasonable for areas likely to regenerate.

There have been other disaster tagging schemes that seem to be used on
occasion, but they always seem to be listed under a particular disaster's
wiki page rather than in some centralised location.

It would be nice to get some more consistency here, but I think the problem
with this sort of tagging is that these tend to be the sort of thing that
should be locally surveyed and updating OSM generally isn't the priority
unless it is somehow part of a specific organisation's workflow.

[1]: https://wiki.openstreetmap.org/wiki/RU:Key:wood

On Sun, 26 Jan 2020 at 22:27, Warin <61sundow...@gmail.com> wrote:

> Hi,
>
>
> I have come across a German mapper who has used 'landuse=brownfield' to
> map some recently burnt areas in Australia.
>
> I know this is not appropriate as it is not a land use, nor does it meet
> the OSM meaning of 'brownfield' in all situations.
>
> Note: this is done in areas, no matter if it is a farm field, recreation
> ground, residential areas etc.
>
> Tagging buildings and other OSM features is easy where they are wholly
> burnt using the life cycle tagging.
>
>
>
> Should this data be entered in OSM?
>
> Are flooded damaged areas mapped? Earthquake damaged areas?
>
>
> If entered how should they be tagged?
>
> The keys 'landuse', 'landcover', 'natural' don't look usable to me.
>
> It may not be possible to use a sub key as the burnt areas do not
> conform to the presently mapped features.
>
> If mapped then the tagging should be inclusive of other disasters
> (natural or not).
>
>
> Thoughts?
>
>
>
> ___
> 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] Divided highways, and not so divided highways, one way or two

2019-10-11 Thread Alan Mackie
On Thu, 10 Oct 2019 at 15:50, Vɑdɪm  wrote:

> Florian Lohoff-2 wrote
> > On Thu, Oct 10, 2019 at 08:38:28AM +0200, Frederik Ramm wrote:
> > Mapping large, multi-lane roads with a "do not cross line" in the
> > middle as single line requires 4-5 times the number of turn
> > restrictions. These are number i am estimating from my own experience
> > mapping it one or the other way.
> > At every way junction one has to model every disallowed way/turn.
> > From my experience this is very error prone.
>
> +1
>
> Also there are some arrangements which probably do not have a simple
> solution even with centre=* tag suggested here.
>
> For example a street with a tramway track in the middle separated from the
> rest of the roadbed by dividing lines at each side which vehicles cannot
> cross: https://goo.gl/maps/VHKbwjMoCVwawHxU9. By the way tramway tracks
> are
> drawn with two separate ways, so a single way line in the middle would make
> you think that the tramway tracks are not in the middle of the roadbed but
> at its sides.
>
> Another example is a bus lane in the middle of the road: 2 lanes of forward
> traffic, a forward bus lane, a backward bus lane, backward traffic
> https://goo.gl/maps/FubkLdHRP6DHLkv86.
>
> Yes another one is a bus lane on the right side, but it turns on the left
> through 4 lanes of normal forward traffic which not allowed to turn left
> https://goo.gl/maps/QFcfDW9h7cQ3UMJaA.
>
> I think for some of the more complex streets some grouping concept is
needed whether via areas or relations. The latter is probably a bit
fragile, the former is at least somewhat consistent with man_made=bridge
and previous 'junction area' proposals.

There was a talk along these lines at SOTM recently, although I'm not so
keen on the areas overlapping:
https://media.ccc.de/v/sotm2019-1038-is-the-osm-data-model-creaking-#t=1263

For the primary way mapping I don't think we should be splitting ways
according to direction unless there is a barrier or median.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviewing wiki pages - Tag:landcover=greenery

2019-07-21 Thread Alan Mackie
On Sun, 21 Jul 2019 at 22:34, Paul Allen  wrote:

> On Sun, 21 Jul 2019 at 22:13, Alan Mackie  wrote:
>
>>
>> On Sun, 21 Jul 2019 at 12:05, Paul Allen  wrote:
>>
>>> Using natural=shrub doesn't cut it if you want to map a shrubbery like
>>> this:
>>> https://goo.gl/maps/LwNZ2Sk1X8fKxt3j9
>>>
>>
>> I'd use barrier=hedge for that one. Yes it's strictly ornamental rather
>> than a livestock barrier, but AFAIK we have no proper distinction for that.
>>
>
> It's not readily apparent from that picture, but it's not a linear
> feature.  It is a dense shrubbery
> covering an area roughly twice as wide as it is long.  Go to
>
> https://www.openstreetmap.org/?mlat=52.08946=-4.64726#map=19/52.08946/-4.64726
> and look at it in an editor such as iD.  There are three trees in it, but
> apart from that is is shrubs.
> Hedges are linear features (or closed polygonal linear features), not
> areas, so it's not a hedge.
> Despite the three trees, it's not woodland, either.
>
> Also, most shrubberies are not as dense as that, they permit passage.  So
> even if we had hedge
> areas, shrubberies wouldn't qualify as they are not impenetrable.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


I agree that we need some tagging for landscaped areas of this type. It
isn't exactly natural=scrub. I have also definitely turned whole fields
into area-hedges by accident.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviewing wiki pages - Tag:landcover=greenery

2019-07-21 Thread Alan Mackie
On Sun, 21 Jul 2019 at 12:05, Paul Allen  wrote:

> On Sun, 21 Jul 2019 at 10:46, Warin <61sundow...@gmail.com> wrote:
>
>>
>> Back to landcover=greenery.
>> Is there a proposal for this?
>>
>
>> landcover=plants looks like a better tag to me.
>>
>
> Better, because not ot all plants stay green all year round.
>
> However, it doesn't cover all common situations.  Grass and trees are
> better tagged as such,
> even though they're both plants.  Better tagged as such because they are
> visually distinctive,
> and part of the reason for mapping details like this is because those
> details may aid
> navigation.
>
> I'd argue that the deprecated landcover=shrubs ought to be revived as part
> of this exercise.
> There are obvious visual differences between grass, bedding plants, shrubs
> and trees.
> Using natural=shrub doesn't cut it if you want to map a shrubbery like
> this:
> https://goo.gl/maps/LwNZ2Sk1X8fKxt3j9
> Admittedly, that looks more like a hedge with area than most shrubberies,
> but it's not a
> match for grass, trees or scrub (it's far more kempt than scrub) and it's
> not a good match
> for plants.  There's no way I could map that as individual shrubs (I can't
> even tell where
> each one is when I'm standing next to them).  Many shrubberies have space
> to walk between
> the individual shrubs, but I couldn't find a picture of one of those.
>
> Could we use landcover=plants for it?  The acid test is giving somebody
> directions.  "Turn
> left after you go past some plants" vs "turn left after you go past some
> shrubs."  Which would
> you use here?
>
> Of course, we could have landcover=plants + plants=shrubs, but then we
> have to justify
> not switching to landcover=plants + plants=grass, landcover=plants +
> plants=trees, etc.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



On Sun, 21 Jul 2019 at 12:05, Paul Allen  wrote:

> Using natural=shrub doesn't cut it if you want to map a shrubbery like
> this:
> https://goo.gl/maps/LwNZ2Sk1X8fKxt3j9
>

I'd use barrier=hedge for that one. Yes it's strictly ornamental rather
than a livestock barrier, but AFAIK we have no proper distinction for that.

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


Re: [Tagging] Tagging mangroves over water?

2018-12-28 Thread Alan Mackie
On Fri, 28 Dec 2018 at 20:30, Joseph Eisenberg 
wrote:

> Have you seen any areas of mangroves tagged over water? That is,
> outside of the coastline or over natural=water or waterway=riverbank
> areas?
>
> I would like to be able to render mangroves with a fill color, as with
> wetland-swamp, a similar environment. But this will case a large
> change in the appearance of the coastline if many areas have been
> tagged outside of the coastline, over the water.
>
> Generally I have been mapping mangroves with the limit of the
> trees/shrubs as the coastline, as recommended on this list a few
> months ago. This appears to be similar to how most swamps are mapped,
> even though a swamp may actually be mostly flooded.
>
> The wiki page does not clearly specify this, but it does seem to imply
> that mangroves are mapped over land, as it recommends using a
> multipolygon if there are areas of open water or "other land" within
> the mangrove - implying that mangroves are a type of "land".
> https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dmangrove
>
> - Joseph
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


As they are tidal and the OSM wiki doesn't even count the part of the beach
that gets wet as beach [1] (despite the picture). I would expect mangrove
to be (almost) entirely on the "wet" side of the coastline.

-Alan


1 : https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbeach
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging