Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Graeme Fitzpatrick]

On Tue, 4 Aug 2020 at 10:17, Jarek Piórkowski  wrote:

> On Mon, 3 Aug 2020 at 19:56, Graeme Fitzpatrick 
> wrote:
> > No, driveway/-through is good for a fuel station, as well as anywhere
> else that you don't get out of your car to be served eg take-away, car
> wash, bottle shop (liquor store)
>
> In some parts of the world you have to get out of your car to get
> fuel. https://en.wikipedia.org/wiki/Filling_station#Types_of_service


Yes, but they are still known as driveways / drive-throughs.

Sorry, I could have worded my previous comment a little better, as it could
suggest that service stations are only "full driveway service" (you don't
get out - & yes, I do remember them :-()

Thanks

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

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

[Graeme Fitzpatrick]

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&oldid=2013942

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

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

[Graeme Fitzpatrick]

On Tue, 4 Aug 2020 at 06:20, Tod Fitch  wrote:

> I’ve yet to find a term or tag name that I like for the case where the
> water disappears from the surface in a desert environment.


& I don't think you're going to find one, because there's "nothing" to
point to on the ground & say "There, that's the spot that the water
disappeared!"

Thanks

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

Re: [Tagging] Rio de la Plata edit war

[Graeme Fitzpatrick]

On Tue, 4 Aug 2020 at 06:43, Joseph Eisenberg 
wrote:

>
> I have previously proposed that estuaries should be mapped by extending
> the coastline upstream to the limit of the estuary, and also mapping the
> area of the estuary as water with water=estuary
>

Good solution!

It's not one thing or the other, so use a third (very accurate) term for
these areas.

Thanks

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

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

[Tod Fitch]

I’ve yet to find a term or tag name that I like for the case where the water 
disappears from the surface in a desert environment. One issue is the location 
will vary depending on how big the storm was (or perhaps for a seasonal stream 
how wet the preceding wet season was). So it might be a tag applied to an 
intermittent way. Or, for simplicity, it might be a tag on the last node of the 
way. And, of course, the only reason for it is to let the QA tools know that it 
is not a mistake.

I wonder if the QA tools could simply ignore connectivity issues for 
intermittent waterways?

Thoughts?

> On Jul 24, 2020, at 2:04 AM, Alan Mackie  wrote:
> 
> 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.
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Jarek Piórkowski]

On Mon, 3 Aug 2020 at 19:56, Graeme Fitzpatrick  wrote:
> No, driveway/-through is good for a fuel station, as well as anywhere else 
> that you don't get out of your car to be served eg take-away, car wash, 
> bottle shop (liquor store)

In some parts of the world you have to get out of your car to get
fuel. https://en.wikipedia.org/wiki/Filling_station#Types_of_service

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

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

[Tod Fitch]

> On Jul 22, 2020, at 10:24 AM, Martin Koppenhoefer  
> wrote:
> 
> 
> Am Mi., 22. Juli 2020 um 17:27 Uhr schrieb Tod Fitch  >:
> It certainly would not be my pick of terms, but it seems manhole=drain has an 
> appropriate definition in the wiki [1] and considerable use [2] for a place 
> that water disappears into a man made structure. Most of them around here are 
> not circular and many appear to be too small for a person to get into when 
> the grate is removed. But OSM has odd tagging for other things so why not 
> this too?
> 
> 
> I would rather try to limit the "odd cases", and maybe even get rid of them 
> in the long term. There is no benefit from using inappropriate terms. If 
> manhole=* is generally considered to be about manholes, why would we want to 
> encourage more usage for non-manhole objects?
> 
> IMHO we should fix the definition in the wiki by making it more precise, as 
> there aren't so many yet.
> 

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

For the location that a surface drainage ditch disappears into an underground 
storm water system. The tag would most often be used on a node.

[1] https://en.wikipedia.org/wiki/Storm_drain
[2] https://en.wikipedia.org/wiki/Storm_drain#Inlet





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Graeme Fitzpatrick]

On Tue, 4 Aug 2020 at 01:10, Matthew Woehlke 
wrote:

>
> It's also often unclear if an otherwise undesignated road with
> provides access to, or navigation of, a larger area (consider a mall
> perimeter road as an example), should be a "driveway".
>
> *If* we need a tag (on which note, I'll point at Jason's list), what
> about something as simple as "service=access"?
>

I've always called those =driveway, but yes, =access would work

Parking lot access roads are a common example; I don't really feel that
> these are "driveways", but I also prefer to reserve "parking_aisle" for
> ways that actually *have* parking spaces along them.
>

I agree, but then you get ones like these (as always, Google just used for
imagery, not mapping!)

Main through road across the front of the shopping centre, with
parking_aisles opening off it, put with a dozen or so specialised parking
spaces (disabled, ambulance, reserved, electric vehicle charging) on it -
does that change it from "access" to another parking aisle?

https://www.google.com.au/maps/@-28.0979691,153.4409585,3a,75y,3.7h,77.96t/data=!3m6!1e1!3m4!1sRK-Dc_i6YeDwLZymf5hZNw!2e0!7i16384!8i8192

Rear "access" road, intended for trucks to reach the loading docks, store
rubbish & industrial bins etc, but also with marked parking spaces
https://www.google.com.au/maps/@-28.0969499,153.4402914,3a,75y,42.6h,82.39t/data=!3m6!1e1!3m4!1sunLAS7MliUIF51mMpGVnUw!2e0!7i13312!8i6656

What is a parking *isle*? I wonder how many of these are typos for
> "aisle"...
>

I'd also go for typo

> service=driveway/drive-through -> Service way for access to a fuel station
>
> IMHO, a drive-through is a very specific type of way which involves a
> service window. *Maybe* you could argue for that in case of a
> full-service fuel station, but I wouldn't use it otherwise. (Note:
> "drive through" implies that the vehicle will engage in stopping but no
> standing or parking.)
>

No, driveway/-through is good for a fuel station, as well as anywhere else
that you don't get out of your car to be served eg take-away, car wash,
bottle shop (liquor store)

Thanks

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

Re: [Tagging] addr:street for routes

[Martin Koppenhoefer]

sent from a phone

> On 3. Aug 2020, at 23:57, Jmapb  wrote:
> 
> The official postal version of the street name may be tagged as 
> `official_name`;


IMHO official_name is not a suitable tag for an officially unnamed road with an 
official postal name. At least not around here, where streets get officially 
named by the people (council). Any other name-tag variant would be better 


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

Re: [Tagging] addr:street for routes

[Jmapb]

On 8/3/2020 4:36 PM, Paul Johnson wrote:



On Mon, Aug 3, 2020, 15:29 Jmapb mailto:jm...@gmx.com>> wrote:


...Regardless, if this general approach is considered valid and
workable, then I'd like to propose the following answer to my original
question:

  * Q) How should `addr:street` be tagged for an address along an
unnamed way which is part of a numbered road-type route relation?
  * A) Check the way for alternative name tags. The official postal
version of the street name may be tagged as `official_name`; if so
that's a good value for `addr:street`. If the way has other name
tags --
such as `alt_name`, `local_name`, `old_name`, or a language-specific
name -- those values may be used. It's also possible to use the
value of
the way's `ref` tag, which should match the name of the route
relation.


Name is only the name, so most route relations wouldn't have a name.


Fair enough. The ones around me have names, but it looks like plenty of
them get by with just ref and network.

So...

  * Q) How should `addr:street` be tagged for an address along an
unnamed way which is part of a numbered road-type route relation?
  * A) Check the way for alternative name tags. The official postal
version of the street name may be tagged as `official_name`; if so
that's a good value for `addr:street`. If the way has other name tags --
such as `alt_name`, `local_name`, `old_name`, or a language-specific
name -- those values may be used. It's also possible to use the value of
the way's `ref` tag, which should correspond to a route relation that
includes the way.



Since the number of different variations on how one might address
something when the street name is on a numbered route, seems like it's
on the data consumer to fuzzy match appropriately to match an
imperfect hit.


I don't disagree, but I don't mind tagging more if it helps a bit.

J

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

Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Joseph Eisenberg]

Everyone, the voting period for natural=bare_ground is still open for 4
more days.

I would recommend voting "no" on the current definition, unfortunately.

As mentioned above, the current definition is far too broad, and could
easily be construed to include areas under construction, areas of bare soil
due to use by people as a pathway or road area, and many sorts of arid and
semi-natural areas, including those that are partially covered by shrubs,
heath, grass or other sparse vegetation, or even areas of farmland that are
currently fallow.

Please see the discussion and objections on
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground

I think it is a good idea to have a way to tag bare soil which is not sand
(natural=sand) or mostly stones (natural=shingle/scree) or mud, but we need
a clear, limited definition which does not fit with human-use areas like
roads, dirt parking lots, construction sites, abandoned quarries etc, and
there needs to be more consideration about when the tag should be used
instead of natural=heath and natural=scrub in arid regions where there are
scattered bushes.

For the proposal author, I would suggest mapping some local features in
your area which would fit the proposed definition, and then come back with
photos plus aerial imagery of the areas which ought to be mapped with this
tag. So far it has been mostly hypothetical, which makes it hard to
understand which sorts of landscapes would qualify for this tag.

- Joseph Eisenberg

On Mon, Jul 27, 2020 at 5:58 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 27. Jul 2020, at 13:41, Michael Montani 
> wrote:
> >
> > I eventually found on-the-ground images of the feature I would like to
> propose / map.
>
>
> are these suggested to be represented as polygons? How would the border be
> determined? I looks from the imagery as if there is a smooth transition of
> these „features“ and neighbouring land which isn’t completely bare. Did you
> try to map some of these and if yes, could you please post a link to an
> area where a few are mapped?
>
> 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?

[Martin Koppenhoefer]

sent from a phone

> 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?
If the native speakers think that „storm“ is required, so be it

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

Re: [Tagging] Rio de la Plata edit war

[Joseph Eisenberg]

Consider the Saint Lawrence river. Often the Rio de la Plata is claimed to
be the widest river estuary in the world, but some maps of the Saint
Lawrence estuary show it extending all the way to the eastern tip of Île
d'Anticosti (Anticosti Island), which would make the mouth of the river
estuary over 300 kilometers wide.

https://www.openstreetmap.org/relation/6122656 - the river centerline,
which extends to the island

The current mapping of the lower estuary, extending to the west end of the
island: https://www.openstreetmap.org/relation/4555382#map=8/49.216/-63.885

Wikipedia map of the Saint Lawrence river watershed, showing the estuary
extending to the east side of the island:
https://en.wikipedia.org/wiki/Saint_Lawrence_River#/media/File:Grlakes_lawrence_map.png

Based on how the Rio de la Plata is currently mapped, it seems that the
Saint Lawrence coastline would have to be moved all the way down to the
very end of the estuary.

However, estuaries are not merely rivers, they are also part of the marine
environment. Just like the Rio de la Plata, the Saint Lawrence estuary is
part of the marine environment, as well as influenced by the river.

I have previously proposed that estuaries should be mapped by extending the
coastline upstream to the limit of the estuary, and also mapping the area
of the estuary as water with water=estuary

This will allow database users to create a reasonable set of water polygons
which include the oceans and all marginal marine water bodies, including
bays, straits and estuaries, while also allowing local mappers to map their
river estuaries as they see fit.

– Joseph Eisenberg

On Mon, Aug 3, 2020 at 12:48 PM  wrote:

>
>
> - Mensaje original -
> > De: "Christoph Hormann" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Lunes, 3 de Agosto 2020 16:27:12
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > On Monday 03 August 2020, mural...@montevideo.com.uy wrote:
> >>
> >> The scientific view, and what can be experienced or observed here is
> >> that the coastline ends in Punta del Este. And the line to Punta Rasa
> >> is a good average of the limit. Where should be put the coasline if
> >> not here?
> >
> > Hello muralito,
> >
> > could you formulate a generic rule for coastline placement similar to
> > what i formulated in
> >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
> >
> > that
> >
> > (a) allows for the coastline placement you favor in case of the Rio de
> > la Plata
> > (b) is based on verifiable physical geography criteria that can
> > practically be checked by mappers and
> > (c) that is compatible to most of the current coastline placements at
> > river mouths around the world?
> >
> > If you can more easily and more precisely formulate such rule in Spanish
> > that would be fine - i am sure we could manage to translate.
> >
> > --
> > Christoph Hormann
> > http://www.imagico.de/
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
> i will try.
>
>
> in my last mail i'm questioning the coastline placement in several rivers.
> so,
> -what are we mapping the coastline for?
> -what we want from the "coastline"?
> -what questions are we going to answer, or could we answer, with that
> modeling of the coastline/world? (or we just draw it for the renderer)
>
> i have read everywhere that OSM is not the map, is the data, and we have
> created and are creating these data for some purpose.
>
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Paul Johnson]

On Mon, Aug 3, 2020, 15:29 Jmapb  wrote:

>
> ...Regardless, if this general approach is considered valid and
> workable, then I'd like to propose the following answer to my original
> question:
>
>   * Q) How should `addr:street` be tagged for an address along an
> unnamed way which is part of a numbered road-type route relation?
>   * A) Check the way for alternative name tags. The official postal
> version of the street name may be tagged as `official_name`; if so
> that's a good value for `addr:street`. If the way has other name tags --
> such as `alt_name`, `local_name`, `old_name`, or a language-specific
> name -- those values may be used. It's also possible to use the value of
> the way's `ref` tag, which should match the name of the route relation.


Name is only the name, so most route relations wouldn't have a name.

Since the number of different variations on how one might address something
when the street name is on a numbered route, seems like it's on the data
consumer to fuzzy match appropriately to match an imperfect hit.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Jmapb]

On 8/3/2020 6:07 AM, Sarah Hoffmann wrote:


There is some fuzzy matching, you can expect to work, for example
abbreviations like street -> st or even New York -> NY. But going from
ref=NY-214 to 'State Highway 214' is already a long stretch that requires
special local knowledge.


Understood. And this is a little out of scope for the tagging list but I
suspect this kind of long-stretch fuzzy matching for numbered routes
will be necessary to return decent search results for a large portion of
the rural USA -- and I'd guess similar problems will be found in other
countries.

At least for the New York State routes, Google, Apple, Microsoft, and
HERE seem to get this right. I don't know of any OSM-centric maps that
do, and I'm not savvy enough to know which are using Nominatim and which
aren't.

(Offhand, AI seems like overkill for this! The variations are pretty
formulaic.)


Note that 'on the ground' doesn't always mean that there needs to be a
physical sign. I consider an envelope (of a letter) as much on the ground
as a street name you get by asking the inhabitants what they call the
street they live on. If you want to express these nuances you can always
use the different variants of name (offical_name, local_name, old_name, ...).
So, yes, in your situation I'd leave out the name tag, add the ref and
a couple of *_name tags that contain the names used in the addresses or
between locals.


The inhabitants call it all of the above. Usually they'll just say "214"
(pronounced "two-fourteen.") I'm not inclined to rifle through people's
mail, but I assure you that every variation *except* the bare "214" will
be written on envelopes and will be delivered. (Assuming the USPS
survives the current attempt at extermination.)


Nominatim's algorithm currently is to match addr:street with any name or
ref tag on a highway (including service, footway, path, etc.) It allows a
little bit of fuzziness but ideally you use exactly the same spelling. If
nothing is found, it simply uses the nearest street.

There is another solution, if you really don't like the requirement of
exactly matching names: associatedStreet relations. They do take precedence
over the matching as explained above. Using those relations you can
use a different addr:street name.

Disclaimer: I have a deep dislike of associatedStreet relations and consequently
they suffer from a bit of neglect in Nominatim. :)


Yes, I've been trying to avoid mentioning associatedStreet! I'm
comfortable creating and maintaining these relations as a last resort,
but heck they're annoying. We'd prefer a solution that would allow a
casual mapper to add or fix addresses along a route.

For now I've had a go with verbose explicit tagging using  _name tags as
you've suggested (ignoring JOSM's "alternative name without name" warnings):

ref=NY 214
official_name=State Route 214
alt_name=Route 214;Highway 214;State Highway 214;New
York 214;New York State Route 214

I've used the USPS-rectified format for the `official_name`, which isn't
exactly right (`postal_name` might be a better tag) but seems close enough.

It's unclear to me how useful it is to cram in all those
semicolon-separated values under `alt_name`. Since this update,
Nominatim is now giving decent (one block away) results for "58 State
Route 214, Phoenicia NY" but nothing for "58 State Highway 214,
Phoenicia NY" so maybe I just have to pick a single `alt_name` and maybe
throw in a `local_name`? (Must confess, this sort of shoehorning starts
to feel a little odd.)

...Regardless, if this general approach is considered valid and
workable, then I'd like to propose the following answer to my original
question:

 * Q) How should `addr:street` be tagged for an address along an
unnamed way which is part of a numbered road-type route relation?
 * A) Check the way for alternative name tags. The official postal
version of the street name may be tagged as `official_name`; if so
that's a good value for `addr:street`. If the way has other name tags --
such as `alt_name`, `local_name`, `old_name`, or a language-specific
name -- those values may be used. It's also possible to use the value of
the way's `ref` tag, which should match the name of the route relation.

Thanks all for your thoughtful replies, and let me know if this seems sane.
Jason


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

Re: [Tagging] Rio de la Plata edit war

[muralito]

> De: "Kevin Kenny" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Domingo, 2 de Agosto 2020 11:03:09
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Sat, Aug 1, 2020 at 6:42 PM Paul Norman via Tagging <
> tagging@openstreetmap.org > wrote:

>> Starting locally, the Fraser River has a strong tidal influence 25km
>> upstream of the coastline/riverbank edge. Fishers report a tidal
>> influence 90km upstream. Wikipedia says the Columbia has tidal influence
>> up to the first dam, which is 120km upstream of the coastline/riverbank
>> edge. There are tidal forecasts published for 75km upstream of the edge.

>> Looking in Europe, the Thames is tidal for 80km upstream of the
>> coastline/riverbank edge.

> Near to me, the Hudson River is an even more extreme example of what you're
> talking about. It is tidal for 134 nautical miles (248 km) north of Mile Zero
> (which is the tip of the Battery, where it enters New York Harbor). The salt
> front ranges from some distance out in New York Harbor during the spring
> snowmelt to about Poughkeepsie (124 km upriver) in a dry summer. Because of
> resonance effects, the tidal range is actually greatest right at the Federal
> Dam in Troy, the northernmost extent of the estuarine region. If you say that
> Troy is on the coast, people will look at you as if you have two heads. If you
> start to explain that well, the river is tidal, and dredged to a depth of 9m 
> to
> accommodate oceangoing vessels, and (yada, yada, yada), they'll say, 'yeah, I
> suppose if you want to be THAT way about it,' and file you mentally under
> 'insufferable pedant.'

> Much farther afield, the Amazon is tidal at least as far as Óbidos, Brasil,
> nearly a thousand km from the river's mouth.

> As a practical matter, given the woes of coastline maintenance, pushing the
> coastline for tens or hundreds of km up most of the world's rivers would be a
> disaster.

We should'nt push up the coastline. i think that tagging coastline inland 
rivers is wrong, no matter the tides. but it depends on what we are using 
"coastline" for. 

And the Amazon mouth should be fixed, but the brazilian is a very active 
community and could do what it should be done by themselves. 

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Christoph Hormann" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Lunes, 3 de Agosto 2020 16:27:12
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Monday 03 August 2020, mural...@montevideo.com.uy wrote:
>>
>> The scientific view, and what can be experienced or observed here is
>> that the coastline ends in Punta del Este. And the line to Punta Rasa
>> is a good average of the limit. Where should be put the coasline if
>> not here?
> 
> Hello muralito,
> 
> could you formulate a generic rule for coastline placement similar to
> what i formulated in
> 
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
> 
> that
> 
> (a) allows for the coastline placement you favor in case of the Rio de
> la Plata
> (b) is based on verifiable physical geography criteria that can
> practically be checked by mappers and
> (c) that is compatible to most of the current coastline placements at
> river mouths around the world?
> 
> If you can more easily and more precisely formulate such rule in Spanish
> that would be fine - i am sure we could manage to translate.
> 
> --
> Christoph Hormann
> http://www.imagico.de/
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


i will try.


in my last mail i'm questioning the coastline placement in several rivers.
so, 
-what are we mapping the coastline for?
-what we want from the "coastline"?
-what questions are we going to answer, or could we answer, with that modeling 
of the coastline/world? (or we just draw it for the renderer)

i have read everywhere that OSM is not the map, is the data, and we have 
created and are creating these data for some purpose.

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Christoph Hormann" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Domingo, 2 de Agosto 2020 7:29:05
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Sunday 02 August 2020, Paul Norman via Tagging wrote:
>>
>> I would consider an area mapped as water both with natural=coastline
>> and waterway=riverbank or natural=water in error. I haven't seen any
>> cases where this is done.
> 
> It is long term established practice at the Elbe and Weser in Germany:
> 
> https://www.openstreetmap.org/way/57390762
> https://www.openstreetmap.org/way/250290462
> 
> https://www.openstreetmap.org/relation/3352832
> https://www.openstreetmap.org/way/28115705
> 
> If you consider that incorrect you also have to ask yourself if you draw
> the same conclusion for natural=bay and natural=strait polygons:
> 
> https://www.openstreetmap.org/relation/1675626
> https://www.openstreetmap.org/relation/9072799
> 
> Even though the overall range of positions is not that large the
> specific placement of the coastline closure is often not done with a
> lot of consideration.  That would certainly very much improve if we had
> visual feedback on the water differentiation in OSM-Carto:
> 
> https://github.com/gravitystorm/openstreetmap-carto/pull/4128
> 
> --
> Christoph Hormann
> http://www.imagico.de/
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


hi.

regarding the coastline placement, e. g. it seems that Hamburg is almost a 
coastal city, because altough it is 90+km from the sea, it is only 10 km away 
from the natural coastline...
all the river is clearly inner waters, and still mapped as coastline. it have 
no sense.
if you use coastline to separate inland (or continents) from seas, this river 
is clearly a river, not an ocean. the coastline should be placed at the mouth.

If someones wants to use OSM coastline to see answer a simple binary question, 
like I'm in the ocean or not, i click on the map in coordinates 51.636686, 
0.649116 and what should be the answer? "no" because is not ocean. well, with 
the current mapping of the coastline is "yes" altough it is more than 20 Km 
inland.
If not, what OSM data should we use to answer this basic question?

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

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Monday 03 August 2020, mural...@montevideo.com.uy wrote:
>
> The scientific view, and what can be experienced or observed here is
> that the coastline ends in Punta del Este. And the line to Punta Rasa
> is a good average of the limit. Where should be put the coasline if
> not here?

Hello muralito,

could you formulate a generic rule for coastline placement similar to 
what i formulated in

https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

that 

(a) allows for the coastline placement you favor in case of the Rio de 
la Plata
(b) is based on verifiable physical geography criteria that can 
practically be checked by mappers and
(c) that is compatible to most of the current coastline placements at 
river mouths around the world?

If you can more easily and more precisely formulate such rule in Spanish 
that would be fine - i am sure we could manage to translate.

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

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Christoph Hormann" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Sábado, 1 de Agosto 2020 14:52:40
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Friday 31 July 2020, Andy Townsend wrote:
>>
>> 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.
> 
> Surface salinity is not a good universal measure for the transit between
> the riverine and the maritime domain because
> 
> a) depending on the threshold you would exclude large maritime areas
> like the Baltic Sea, Hudson Bay or the Sea of Azov.
> b) at the mouth of a river salinity often varies significantly between
> the surface layer and deeper water because saltwater is heavier.
> 
> Suspended particles are also often not a good measure because we are
> usually talking about very fine particles that stay suspended for a
> long time and in shallow water currents can re-suspend silt from the
> bottom as well.  The presence of suspended particles is therefore an
> indication of a lack of large volume dilution of the water in the area,
> not of the dominance of river water over sea water in general.  See for
> example
> 
> http://maps.imagico.de/#map=7/32.361/122.212&lang=en&l=sat&ui=10
> 
> where strongly visible turbidity reaches up to more than 50km from the
> shore into the open sea.
> 
> As i wrote in my old proposal on the transit placement looking at the
> cross section of the river and the resulting average water flow
> velocity due to discharge gives you a relatively good idea about the
> situation.  In case of the Rio de la Plata you have an average
> discharge of 22000m^3/s.  At the claimed baseline you have an average
> water depth of about 20m and a width of more than 200km that is an
> average waterflow velocity of 6mm/s.  At Montevideo with a width of
> about 100km and a depth of about 8m you get an average velocity of
> 3cm/s.  That is still smaller than typical coastal currents induced by
> tides and wind (which the paper you cited confirms).  But you are not
> that far off any more and around where the average water depth is about
> 5m you will have reached the lower limit my proposal suggests.
> 
> I still think the people best qualified to make the assessment where
> exactly the transit is best placed are those with local knowledge, who
> have first hand knowledge of the effects of waves, tides and currents
> on the shore over the course of the year as long as their perspective
> is not dominated by political considerations (i.e. they are able to
> look at this purely from a physical geography perspective).
> 

Right. For all this reasons the best place to put the coastline is in the line.
The only reason to continue tagging the coastline inland in the river is to 
render it,
 or to see it in the render like some people thinks it should be, but it is not 
the real coastline.

The scientific view, and what can be experienced or observed here is that the 
coastline ends in Punta del Este. 
And the line to Punta Rasa is a good average of the limit. Where should be put 
the coasline if not here?

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

> De: "Alan Mackie" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Sábado, 1 de Agosto 2020 13:26:06
> Asunto: Re: [Tagging] Rio de la Plata edit war

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

there is no noticeable tides. tides here are meterological, not astronomical. 
e.g the river between Buenos Aires and Colonia is 3m depth average, with a few 
channels to navigate. if you are not cautious, with a change of wind the water 
withdraws and your sailboat remains in the mud without notice. 

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

> De: "Paul Norman via Tagging" 
> Para: tagging@openstreetmap.org
> CC: "Paul Norman" 
> Enviados: Sábado, 1 de Agosto 2020 3:18:34
> Asunto: Re: [Tagging] Rio de la Plata edit war

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

Hi. 

for sure, the coast of the ocean starts in Punta del Este, Uruguay and in Punta 
Rasa (San Clemente). My personal experience is in Punta del Este, and it is 
incredible how the beaches changes from this point to the east and to the west. 
There are two very different kind of coast, to the east one with waves, wind, 
salinity, notable changes in the seabed of the beaches, currents, cold salty 
water, etc. The other one to the west is calm, almost no winds, no currents, 
very small waves of less than 40-50 cm, very low salinity, fresh water not so 
cold. 

The scientific studies you can read matches what can be seen here in the 
ground, in the beaches, and in the videos i linked in my previous mail. 
No, its hard to see it from aerial imagery, but it seems that i'm discusing 
with armchair mappers, and they dont put any argument of why the coastline in 
between of Punta del Este-Punta Rasa is a bad idea. For the obviously changing 
limit of the river/ocean, this line is "like an average", like the mean high 
water springs is for the ocean shore. 

on the other hand, what about the local knowledge? the on-the-ground survey? 
those does'nt have value in this discussion? 

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

Hi,

- Mensaje original -
> De: "frederik" 
> Para: tagging@openstreetmap.org
> Enviados: Viernes, 31 de Julio 2020 19:16:50
> Asunto: Re: [Tagging] Rio de la Plata edit war

> Hi,
> 
> I don't know the region myself so I am limited to anecdotal evidence as
> found on the web:
> 
> * Montevideo clearly brands itself as having "a coast" (from
> welcomeuruguay.com: "Costa de Oro" (Gold Coast) is the name given to the
> great variety of beaches stretching from La Barra de Carrasco, in
> Montevideo, to Solís Grande Creek, ...)
> 
> * next city east is called "Ciudad de la Costa"
> 
> * Buenos Aires, on the other hand, seems to be mainly referred to as
> being "on the SHORE of Rio de la Plata"
> 
> * Wikipedia entry on Montevideo calls Rio de la Plata an "arm of the
> Atlantic ocean"
> 
> It is obvious that, regarding the official definition, both countries
> have a shared interest of defining the coast as far out on the sea as
> legally possible. Therefore, I am not sure if our usual approach of
> "letting the locals decide" will work here. Our other usual approach is
> that of "truth on the ground" and the 200km+ straight line from Punte
> del Este to Cabo San Antonio certainly stretches *anybody's* definiotion
> of a coastline!
> 
> The largest estuary in the United States, Chesapeake Bay, is almost
> completely mapped as coastline, only changing to a natural=river polygon
> very far inland - though I haven't researched currents or salinity.
> 
> Are there other examples of large bays/estuaries?
> 
> 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



As with any terms in OSM context, we should'nt literaly translate the terms 
betwen languages because we can incurr in errors. Sometimes also between 
dialects of the same language the same word have different meanings. In this 
case, "coastline" should'nt be translated to spanish as "costa". Acording to 
RAE.es (official institution for the spanish language), it defines "costa" as 
"Orilla del mar, de un río, de un lago, etc., y tierra que está cerca de ella". 
Translated, in spanish "costa" does not mean only seashore ("Orilla de mar"), 
it could be a river bank ("Orilla de río"), lake shore ("Orilla de lago". So 
that any city or comunity defines itself as "costa" or "costera", or "SHORE" or 
any other term, is not related to the OSM coastline definition. It is also 
different from the definition of "coast" from Oxford Dictionary (6th edition 
that i have in hand), which refers to the land besides the ocean or the sea.

In some cases, like this, the wikipedia article lacks the accuracy to define 
river. The river starts in Paralelo Hito Punta Gorda and ends in the line 
between Punta del Este and Punta Rasa.

Here in Uruguay we have two "coast", the oceanic coast (natural=coastline) 
which begins in Punta del Este and goes to the border with Brazil.
The other "coast" is the river, which is why Montevideo, Buenos Aires, etc, are 
known as "ciudad ribereña" (riverside city).
The oceanic coast in the Argentina side, also starts in Punta Rasa. Those two 
different coast are very different
All this facts are clearly visible and verifiable being here. Just like other 
thing they are not visible in aerial imagery [3]. 

The motivation to not map as coastline are not political, but technical. The 
political issues were solved at least 60 years ago, with scientific consensus. 
[1][2]
There is no other place where the coastline could be placed. There has been, 
and there is wide consensus in both local communities (i cannot say absolute 
consensus without checking). The limit of Rio de la Plata is historically 
recognized by politics and scientists. The legal, or official definition is 
settled at least 60 years ago, by political means (binational protocols, UN 
international treaty, IHO definitions), y scientific studies. Also newer/modern 
scientific studies and papers, based on salinity, batimetry, water flows, 
sediments, mathematical models, etc. confirms what the old scientific studies 
and political have agreed that the limit of the ocean is between Punta del Este 
and Punta Rasa, so there should be no discussion here.
Besides this, in 2016 the UN extended the sovereignty rights of Uruguay in the 
continental platform for 350 nautical miles [11], but this is another issue and 
is not mapped yet. And speaking about politics, both navies pursues industrial 
fishing pirates, mostly from Asia. 

This is just a very width river, with a basin size like India, or 10 times 
Germany, it obviously brings a very large amount o fresh water, which 
influences the salinity of the ocean waters several tenths of km inner into the 
ocean from Punta Rasa or Punta del Este.

According to some people, mapping the coastline where I think where it should 
be, and where it wa

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Matthew Woehlke]

On 01/08/2020 20.40, David Dean wrote:

I'm interested in proposing and/or documenting existing tagging approaches
of the wiki to ensure that all highway=service ways can have a service=?
associated tag. Having done, so I'm planning on resurrecting
https://github.com/westnordost/StreetComplete/issues/808 to help people get
all service roads appropriately tagged in their area.

At the moment, service=? can be (according to the wiki at
https://wiki.openstreetmap.org/wiki/Key:service):

* service=parking_aisle
* service=driveway
* service=alley
* service=emergency_access
* service=drive-through

But service roads are also used for the 'main ways on a parking lot', and
there is also an indication of access to multiple businesses (like in an
industrial estate etc), and it looks like the documented way is to not to
provide a service=? tag in this case.

This seems problematic to me from a map maintenance purpose, as how do we
know if a highway=service just hasn't had a service=? tag applied yet, or
if it is one of the exceptions that does not get a service=? tag (and which
one is it?)


As someone who has recently tagged a number of ways thusly, I have to 
strongly agree that there needs to (continue to) be a way to mark such 
roads. It's also often unclear if an otherwise undesignated road with 
provides access to, or navigation of, a larger area (consider a mall 
perimeter road as an example), should be a "driveway".


*If* we need a tag (on which note, I'll point at Jason's list), what 
about something as simple as "service=access"? (IOW, Martin's line of 
thinking, except lose the confusing "collector".)


That said, service=main might be a good choice.


I would like to try to understand the highway=service usages that don't
have a current documented service=? tag and either propose an appropriate
tag or find examples of existing tagging to document.


You might start by taking a look at all such routes in Quantico, VA (as 
any such were probably tagged by me).


Parking lot access roads are a common example; I don't really feel that 
these are "driveways", but I also prefer to reserve "parking_aisle" for 
ways that actually *have* parking spaces along them.


Of course, Jason's list is quite good; this is more along the lines of 
if you want to go look at some *extant* examples where the lack of 
service= is known to be intentional.



At this stage I think appropriate tagging for some of the missing service=?
tagging indicated in the documentation would be:

service=parking -> main way in a parking lot, for connecting


As noted by others, I would strongly prefer parking_access.


service=parking_isles (used almost 2K times already:
https://taginfo.openstreetmap.org/keys/service#values)


What is a parking *isle*? I wonder how many of these are typos for 
"aisle"...



service=driveway -> also used for access to multiple businesses (like in an
industrial estate, etc)


*Maybe*, but this seems like an excessive stretch of what most people 
would consider a "driveway".


OTOH, my suggested service=access could be seen to overlap with 
driveway. Maybe it would be better to provide that while also narrowing 
the definition of "driveway"?



service=driveway/drive-through -> Service way for access to a fuel station


IMHO, a drive-through is a very specific type of way which involves a 
service window. *Maybe* you could argue for that in case of a 
full-service fuel station, but I wouldn't use it otherwise. (Note: 
"drive through" implies that the vehicle will engage in stopping but no 
standing or parking.)


--
Matthew

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

Re: [Tagging] addr:street for routes

[Matthew Woehlke]

On 31/07/2020 15.39, Martin Koppenhoefer wrote:

the authority for names are the local people. I would bet that some
of them would refer to this particular road as State Highway 214 if
they should name it in a formal way. NY 214 is a ref, no doubt, and
is fine to have, but so is State Highway


...and then there is, for example, 
https://www.openstreetmap.org/way/5640056. According to OSM, this is 
"Clifton Park Blvd¹", but I don't think I've ever called it anything 
other than "146".


(¹ ...except not abbreviated, but I'm lazy.)

--
Matthew

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Paul Allen]

On Mon, 3 Aug 2020 at 14:02, Tobias Zwick  wrote:

Maybe service=property_access would be a little more clear.


Or not.  Because it overlaps with service=driveway.  Especially as property
is often used to describe dwellings.


> Of course, strictly speaking, pretty much all the above are also
> "properties". Is
> there a word in English that would describe more accurately those kind
> of hmm, bigger properties, like industrial and commercial parks,
> hospital grounds etc etc (as mentioned in an earlier post)?
>

For universities and some hospitals, campus.  Doesn't really work for
mid-range
though.

How about service=internal or something similar?  A road, or network of
roads,
internal to an area such as a university, hospital, caravan park, military
base,
manufacturing facility, business park, industrial estate, etc.

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tobias Zwick]

> For the second type of highway=service with no service tagging, what
> about using service=access? 

The issue with this is that basically this is the definition of
highway=service already without any extra tags: It provides access to
something. Be it the rear/side of buildings (alley), the garage of a
house (driveway), the fuel dispensers on a filling station
(drive-through) or to the individual parking spaces on a parking
(parking_aisle).

Maybe service=property_access would be a little more clear. Of course,
strictly speaking, pretty much all the above are also "properties". Is
there a word in English that would describe more accurately those kind
of hmm, bigger properties, like industrial and commercial parks,
hospital grounds etc etc (as mentioned in an earlier post)?

Cheers
Tobias


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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tobias Zwick]

service=parking_access also sounds most clear to me.

On the other hand, service=parking is already used almost 2000 times so
documenting that as "main access road in a parking" would just be
documenting the status quo, no proposal necessary, which is certainly
easier.

IF after research one can actually conclude that service=parking is
really used for that purpose and not for all kinds of roads in parking
that should actually be parking_aisles. So before reaching a conclusion,
I'd strongly suggest to first analyse a bit what really is the status
quo with service=parking.

Cheers
Tobias

On 03/08/2020 11:25, Martin Koppenhoefer wrote:
> Am Mo., 3. Aug. 2020 um 11:06 Uhr schrieb Tom Pfeifer
> mailto:t.pfei...@computer.org>>:
> 
> Possibilities discussed were:
> 
> service=parking_access
> service=main
> service=access
> service=major
> 
> 
> 
> apart "access", all of these seem better than "parking". My preference
> would go to the more neutral "main" or "major"
> 
> 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] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Paul Allen]

On Mon, 3 Aug 2020 at 05:09, David Dean  wrote:

>
> For the second type of highway=service with no service tagging, what about
> using service=access?
>

How about because not all service roads that don't currently fit into
service=* would be viewed by some as access roads?  The service
roads in a university campus or a caravan park come to mind.  I have
to stretch my mental model of "access road" to breaking point to
call those access roads.

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

Re: [Tagging] addr:street for routes

[Sarah Hoffmann]

On Fri, Jul 31, 2020 at 06:06:37PM -0400, Jmapb wrote:
> On 7/31/2020 4:24 PM, Sarah Hoffmann wrote:
> 
> > Put one of the variants into addr:street and then all the variants
> > as alternative names onto the road. Obviously that stretch of road
> > is referred to under all these names, so this is what we should map.
> 
> Putting aside the question of *which* variant to put into `addr:street`,
> this sounds like an approach that could work. But we might end up with
> something like `alt_name=Highway 214;Route 214;State Highway 214;New
> York 214;NY-214;New York State Route 214` (or the name_1 ... name_n
> equivalents). I could live with that if it actually helped the geocoding
> but it's not exactly graceful.

The question here is always how much guessing you expect a geocoder to
do. We could train the geocoder to do a lot of fuzzy matching on the
street name variants as the one above. This may sound like a good idea to
make mapping easier for you but in the long run it doesn't help.
For one thing, if Nominatim gives you two or three simple rules how the
matching works, then you can easily figure out yourself what is going on
and fix it. If the matching is more complicated (possibly even involving
AI), then you sooner or later run into an issue where you just don't
understand why things go wrong. The other problem is that Nominatim is
not the only geocoder out there. You may expect one geocoder to do clever
things to understand the tagging but there is very little chance that all
data users will go through the trouble. So being explicit in your tagging
makes the data more useful.

There is some fuzzy matching, you can expect to work, for example
abbreviations like street -> st or even New York -> NY. But going from
ref=NY-214 to 'State Highway 214' is already a long stretch that requires
special local knowledge.

> 
> Ultimately, though, these are alternate names for the route, not for the
> stretch of road. (Which might have its own list of names! For instance,
> a particular stretch of Ulster County Route 40 is known as Main Street,
> Plank Road, Old Plank Road, Old Route 28, and Mount Tremper-Phoenicia Road.)
> 
> > It really doesn't matter that the road has officially no name. The
> > goal is to map what's on the ground.
> 
> For the road itself, what's on the ground is simply the highway shield
> with the number 214. There's no textual version of the name anywhere
> (except as used for the addresses of residences and POIs.) Best practice
> for these sorts of roads, I'm told, is to omit `name=*`, tag `ref=*`,
> and add to a route relation.

Note that 'on the ground' doesn't always mean that there needs to be a
physical sign. I consider an envelope (of a letter) as much on the ground
as a street name you get by asking the inhabitants what they call the
street they live on. If you want to express these nuances you can always
use the different variants of name (offical_name, local_name, old_name, ...).
So, yes, in your situation I'd leave out the name tag, add the ref and
a couple of *_name tags that contain the names used in the addresses or
between locals.

> For the addresses along the road, the vast majority are signed with just
> a housenumber, and those POI signs that do include a street name are
> inconsistent. Government data sources are also inconsistent.
> 
> But an on-the-ground mapper can observe that those housenumbers belong
> to this road, which here is known only by its route number. I feel there
> should be a way to encode that observation without asking the mapper to
> choose a particular textual representation of the route's name...
> especially since it's hard to do that in a consistent manner.
> 
> (Whatever the solution, my aim here is to get an address search that works!)

Nominatim's algorithm currently is to match addr:street with any name or
ref tag on a highway (including service, footway, path, etc.) It allows a
little bit of fuzziness but ideally you use exactly the same spelling. If
nothing is found, it simply uses the nearest street. 

There is another solution, if you really don't like the requirement of
exactly matching names: associatedStreet relations. They do take precedence
over the matching as explained above. Using those relations you can
use a different addr:street name.

Disclaimer: I have a deep dislike of associatedStreet relations and consequently
they suffer from a bit of neglect in Nominatim. :)

Sarah

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Martin Koppenhoefer]

Am Mo., 3. Aug. 2020 um 11:06 Uhr schrieb Tom Pfeifer <
t.pfei...@computer.org>:

> Possibilities discussed were:
>
> service=parking_access
> service=main
> service=access
> service=major



apart "access", all of these seem better than "parking". My preference
would go to the more neutral "main" or "major"

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tom Pfeifer]

I agree that it would be helpful to distinguish more subtypes of 
highway=service.
However I find the proposed 'service=parking' misleading, as it suggests the 
way itself is
used for parking, not that it provides access to such facility.

I started a similar discussion four years ago, here is the thread start:
https://lists.openstreetmap.org/pipermail/tagging/2016-March/028982.html

Possibilities discussed were:

service=parking_access
service=main
service=access
service=major

tom

On 03.08.2020 10:39, Martin Koppenhoefer wrote:



sent from a phone


On 3. Aug 2020, at 06:09, David Dean  wrote:

On the main parking road, I think we are largely in agreement that 
service=parking would be a good addition to OSM documentation (and is already 
in use throughout the world, as such).




if we need a specific service subtag for the access to parkings (which is 
already implicit through the fact that the road leads to a parking, and which 
leads to uncertainty which tag to choose if the road leads to parking and 
another use, like delivery for supermarkets), I would prefer are more verbose 
tag, as it is foreseeable that “parking“ will be confused with “parking_aisle”.

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] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Martin Koppenhoefer]

sent from a phone

> On 3. Aug 2020, at 06:09, David Dean  wrote:
> 
> On the main parking road, I think we are largely in agreement that 
> service=parking would be a good addition to OSM documentation (and is already 
> in use throughout the world, as such).



if we need a specific service subtag for the access to parkings (which is 
already implicit through the fact that the road leads to a parking, and which 
leads to uncertainty which tag to choose if the road leads to parking and 
another use, like delivery for supermarkets), I would prefer are more verbose 
tag, as it is foreseeable that “parking“ will be confused with “parking_aisle”.

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