Re: [Tagging] Feature Proposal - Voting - Pumping proposal

[Martin Koppenhoefer]

sent from a phone

> On 22. Nov 2020, at 02:32, François Lacombe  wrote:
> 
> It's true proposed tagging deprecates the current pump=* definition according 
> to rationale and wishes to use the pump word in a more appropriate way.


this would deprecate around 20k pump values describing a pump type, plus 15k 
yes/no.

Looking at the no-values, 23% are not in combination with man_made 
https://taginfo.openstreetmap.org/tags/pump=no#combinations
i.e. this is also used on other objects to state buildings there is no pump.
I would also suggest you modify your proposal in a way that it is compatible 
with the current use of the pump tag

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

Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?

[Dave F via Tagging]

To me, boardwalk describes the design & appearance rather than the 
surface construction: An elevated walkway.

Although I do admit that's mostly influenced by The Drifters song.

DaveF


On 21/11/2020 23:20, Mateusz Konieczny via Tagging wrote:

Is there some value in surface=boardwalk tag?

It seems to be a duplicate of surface=wood.

___
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 - Pumping proposal

[François Lacombe]

Joseph,

It's true proposed tagging deprecates the current pump=* definition
according to rationale and wishes to use the pump word in a more
appropriate way.

However, it would be ok to define mechanical_driver=powered for situations
when mappers aren't able to determine a more precise value.
That would preserve the current distinction made on HDM render with
mechanical_driver=manual/powered and offer possibilities to define a more
detailed knowledge.

Giving more details about pumping capabilities of water wells would cause
upgrading work for renders anyway: they have to support more pump=* values
or drop it in favour of mechanical_driver=*
I now agree on the ability to state 'this water well has powered pumping
capabilities' in case of no additional knowledge but don't get why limiting
knowledge to manual/powered would be desirable.

All the best

François

Le sam. 21 nov. 2020 à 06:24, Joseph Eisenberg 
a écrit :

> On the Talk page, the proposal author has now ignored two different
> requests to change the new pump=values to a different key like
> pump_mechanism, which would allow the continued use of pump=manual and
> pump=powered.
>
> The author claims: "I find current tagging meaningless (with all due
> respect to people who created it in the past)"
>
> This is absolutely disrespectful to the current mappers using this tag to
> specify the type of water well found in lower-income countries.
>
> Perhaps you have never lived in a place where people get their drinking
> and washing water from public or semi-public wells. In these places it is
> quite important to know if a well is just a hole in the ground where you
> need to use a bucket and rope to draw out water (pump=no), or if there is a
> mechanical pump handle which you can physically operate, with some amount
> of force, to pump out bursts of water (pump=manual).
>
> And the other type of well is "a well that is attached to pipes and a
> motorized pump", which is usually powered by electricity but sometimes by a
> diesel motor. In this type of well you don't have to use any physical
> effort at all, you just flip a switch or open a faucet and water comes out
> - as most Westerners are accustomed to enjoy in their own homes.
>
> But you will need electricity or fuel to operate it. So usually a
> man_made=water_well + pump=powered is much more convenient, but when the
> power goes out or there is no fuel, it can be nearly useless, while a
> pump=manual is now much more helpful.
>
> I am quite frustrated that this proposal has gone forward even though
> these concerns were brought up months ago on the Talk page.
>
> -- Joseph Eisenberg
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

> Alex noted that he found that the "lane" value might have a different
> meaning already. I'll look into that and come up with an alternative.

I did this now, I looked for in which situations ...

parking:lane:*:parallel = lane
parking:lane:*:parallel = on_lane
parking:lane:*:parallel = in_lane

... were used. The tag (and the parking lane tag in general, anyway) is 
used only very few times in relation to the number of streets. It is 
still quite new. Together, less than 1% of all parallel parking lanes 
are tagged like that.
But for what it's worth, "on_lane" is the most popular of the above 
(probably because of its consistency with "on_street" and "on_kerb") and 
most of the times were used to describe situations like this:


https://www.google.de/maps/@49.0056633,8.4349157,120m/data=!3m1!1e3

So, parking is on the street itself (not on kerb, not street side) but 
has its own marked lane.


In any case, whatever if someone used "street_side" as a value for the 
parallel parking lane or "on_lane", "on_kerb", "lay_by" or 
"painted_area_only", its all the same as in that it does define an own 
dedicated space for parking cars as opposed to "on_street" and 
"half_on_kerb".


And in the end, what will give the most precision in measuring the 
drivable space (criteria #2) is to look at the width or est_width tag. 
No need to let the lanes tag duplicate this information but less precise.
If the lanes tag was used for that, then it would become eventually 
obsolete because it wouldn't carry any original information that cannot 
be recorded more precisely and less subjectively with another tag. On 
the other hand, data consumers attempting a visualization (criteria #1) 
need the information how many lanes are tagged.
So, I am going ahead an will add these two words to the documentation of 
the lanes key.


Cheers
Tobias

On 20/11/2020 14:03, Tobias Zwick wrote:

You stated how you would tag that, which I'd summarize as

 > Any parking on the street surface is subtracted from the lanes as the
 > lanes-tag first and foremost indicates the number of usable lanes, not
 > the number of marked lanes

Ok, so apparently there is no consensus on that if there are marked 
lanes, it's always the marked lanes that first and foremost should be 
counted.


But let's not fall in the trap that everybody states how he tags it and 
in the end we can agree that we cannot agree. We have a problem to 
solve, let's identify it and find a solution together. I'd say, the core 
of it is:


How to tag if usable lanes deviate from marked lanes?


And the solution we are aiming at should fulfill at least these criteria:

1. that the street layout can be interpreted correctly and completely
    (for data visualization, f.e. JOSM lanes plugin, abstreet, renderers
     ...)
2. that the effective usable width of the street for car traffic can be
    ascertained (for routers)

---

The criteria above were already in my head when I wrote the second half 
of my intial post: When do usable lanes deviate from marked lanes?
-> When there are cars not parking in an own dedicated parking lane but 
just at one side of the street. Hence, this example:


https://westnordost.de/misc/parallel_parking_lane.png

If these situations are tagged like this...

(1)
lanes = 2
parking:lane:right = parallel
parking:lane:right:parallel = lane

(2)
lanes = 2
parking:lane:right = parallel
parking:lane:right:parallel = on_street

..., both criteria are fulfilled, given the definition for lanes is:
"if marked, number of marked lanes. Dedicated and marked parking lanes 
don't count" (adding "dedicated and marked" to wiki definition).


For visualization, the lanes tag can then be directly used. Routers will 
want to additionally look at the parking lanes tag to see whether the 
effectively usable road is being narrowed by parking lanes with 
on_street or half_on_kerb and subtract that from the usable width.


I further suggested this solution because of its separation of concerns: 
Lanes is then just the marked lanes, no need to factor in possible 
parking lanes into that one tag and estimate whether the parking cars 
subtract enough of lane space to decrease it by one.


So, the definition of parking lanes go into the parking:lane tag, 
including where it is located. Well, and that's already how it is done, 
so that's not a real change.


The change here would be to find a tag the describes "parking lane is on 
street surface but has its own space/lane". Alex noted that he found 
that the "lane" value might have a different meaning already. I'll look 
into that and come up with an alternative.


Tobias

On 20/11/2020 09:16, Mateusz Konieczny via Tagging wrote:
I would describe https://westnordost.de/misc/2or1lanes.jpg 
 as road

with
- one lane driveable by full-size vehicles
- one parking lane

And tag it as:
lanes=1
parking:lane:both=parallel (judging from what is visible about left side)

Additional detail that I am 

Re: [Tagging] surface=boardwalk? is it duplicate of surface=wood?

[Andrew Harvey]

Boardwalk isn't really a good surface value as boardwalks can be made up of
a variety of materials not only wood.

We do have bridge=boardwalk but that always feels award when
the boardwalk is only elevating 10cm off the ground.

On Sun, 22 Nov 2020 at 10:22, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Is there some value in surface=boardwalk tag?
>
> It seems to be a duplicate of surface=wood.
> ___
> 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] surface=boardwalk? is it duplicate of surface=wood?

[Graeme Fitzpatrick]

On Sun, 22 Nov 2020 at 09:22, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Is there some value in surface=boardwalk tag?
>
> It seems to be a duplicate of surface=wood.
>

Fine distinction I know, but to me =wood would suggest a solid, unbroken
floor eg dance floor or corridor; while =boardwalk suggests that it's
possibly slightly (?) uneven & that there are possibly gaps in between each
plank.

https://upload.wikimedia.org/wikipedia/commons/thumb/0/0b/Swampy_But_Pretty_Bog_In_Fiordland_NZ.jpg/1200px-Swampy_But_Pretty_Bog_In_Fiordland_NZ.jpg

Thanks

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

[Tagging] surface=boardwalk? is it duplicate of surface=wood?

[Mateusz Konieczny via Tagging]

Is there some value in surface=boardwalk tag?

It seems to be a duplicate of surface=wood.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface=rock

[Joseph Eisenberg]

My understanding about this is that there is a difference between British
English usage and American usage - especially in the western USA.

The English seem to have an idea that "rock" is for mostly solid, immobile
"bedrock", while a "stone" is a mobile, separate piece of mineral which you
might pick up if you are strong enough, or at least move with a piece of
heavy machinery. Hence the distinction between natural=stone and
natural=bare_rock in the wiki, and the different definitions in the OED
(lexico):

Rock: The solid mineral material forming part of the surface of the earth
and other similar planets, exposed on the surface or underlying the soil or
oceans - https://www.lexico.com/en/definition/rock - example "‘the beds of
rock are slightly tilted’"

Rock: "the dry solid part of earth's surface, or any large piece of this
that sticks up out of the ground or the sea"
https://dictionary.cambridge.org/us/dictionary/english/rock

Stone: https://www.lexico.com/definition/stone - "Hard solid non-metallic
mineral matter ... especially as a building material. ‘the houses are built
of stone’" and especially the next definition: 1.2 count noun "A small
piece of rock found on the ground."

Stone: "the hard, solid substance found in the ground that is often used
for building, or a piece of this" -
https://dictionary.cambridge.org/us/dictionary/english/stone

But American English and perhaps other dialects do not always maintain this
distinction, in my experience.

So in theory surface=stones would be best when there are large separate
stones, similar to surface=cobblestone or surface=scree(?), while
surface=bare_rock or surface=rock would suggest mostly solid bedrock, if
these tags are actually going to be used in different ways based on British
English. But it is unlikely that most mappers will understand the
difference.

-- Joseph Eisenberg

On Sat, Nov 21, 2020 at 11:25 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Nov 21, 2020, 17:43 by o...@westnordost.de:
>
> rock „pieces“ would be tagged as „stone“ I guess?
>
>
> Not so sure about that, then it would be surface=stones, (note the plural)
> wouldn't it?
>
> I am completely fine with both versions.
> I created today https://wiki.openstreetmap.org/wiki/Tag:surface%3Drock
> where I described surface=rock as fitting for them - but feel free to
> change this
>
> - Rock implies a rough naturalness
>
> +1
>
> - Steps made of large (single-piece) hewn stone columns would be called
> 'stone steps'
>
> so surface=stone (surface=stones) would be more fitting for them?
>
> - Bare [rock] implies the lack of rubble on top
>
> Small amount: yes
> Complete lack of it: no.
>
> See for example
> https://commons.wikimedia.org/wiki/File:Krywan_podejscie.jpg
>
> Especially for easily eroding rock that is breaking piece by piece some
> rubble will be always
> present.
>
> - Scree is specially loose
>
> +1
>
> - Personally I think bare_rock and stone are synonyms here, unless someone
> thinks there's a difference.
>
> Yes, even if we would invent some differences none would be present in de
> facto usage
> (different areas with different differences and subtle distinctions)
>
> rock = rough natural stone, could be loose stones too
> stone = smooth stone / bare rock, could be hewn
> bare_rock = probably similar to stone, definitely no loose stones
> scree = surface like (large) gravel, natural
> rocky = scree is rocky, piles of differently sized rocks are rocky
>
> Overall I think that I am fine with surface=rock, but I am not opposed to
> also other
> values (though I am not going to make proposals or wiki pages for them)
> ___
> 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] surface=rock

[Mateusz Konieczny via Tagging]

Nov 21, 2020, 17:43 by o...@westnordost.de:

>> rock „pieces“ would be tagged as „stone“ I guess?
>>
>
> Not so sure about that, then it would be surface=stones, (note the plural) 
> wouldn't it?
>
I am completely fine with both versions.
I created today https://wiki.openstreetmap.org/wiki/Tag:surface%3Drock
where I described surface=rock as fitting for them - but feel free to change 
this

> - Rock implies a rough naturalness
>
+1

> - Steps made of large (single-piece) hewn stone columns would be called 
> 'stone steps'
>
so surface=stone (surface=stones) would be more fitting for them?

> - Bare [rock] implies the lack of rubble on top
>
Small amount: yes
Complete lack of it: no.

See for example https://commons.wikimedia.org/wiki/File:Krywan_podejscie.jpg

Especially for easily eroding rock that is breaking piece by piece some rubble 
will be always
present.

> - Scree is specially loose
>
+1

> - Personally I think bare_rock and stone are synonyms here, unless someone 
> thinks there's a difference.
>
Yes, even if we would invent some differences none would be present in de facto 
usage
(different areas with different differences and subtle distinctions)

> rock = rough natural stone, could be loose stones too
> stone = smooth stone / bare rock, could be hewn
> bare_rock = probably similar to stone, definitely no loose stones
> scree = surface like (large) gravel, natural
> rocky = scree is rocky, piles of differently sized rocks are rocky
>
Overall I think that I am fine with surface=rock, but I am not opposed to also 
other
values (though I am not going to make proposals or wiki pages for them)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Eric H. Christensen via Tagging]

You cannot point to other area that may, in fact, be improperly mapped as an 
example when they are like that because locals have been shouted down for doing 
it correctly. The fact that this keeps coming back up literally means that 
there is not universal agreement that "marginal seas", whatever that means, are 
to be mapped with natural=coastline.

The Chesapeake Bay is an estuary that, by definition, opens to the sea. It 
can't be a sea and open to a sea at the same time. In this environment, it is 
different from the ocean in which it opens into and is also different from the 
tributaries that feed it. These are protected waters for ships. You won't find 
any high seas forecasts for the Bay unlike the ocean. The Bay is also brackish 
and not defined as salt water, unlike the ocean.

If the rendering engine isn't showing it correctly, fix that; *that's* what's 
broken.

Eric

‐‐‐ Original Message ‐‐‐
On Saturday, November 21, 2020 1:14 PM, Joseph Eisenberg 
 wrote:

> Eric,
> I don't think the previous discussion is quite as inconclusive as your 
> evaluation.
>
> While it is true that there is not widespread agreement on where the 
> natural=coatline ways should transect a river mouth or river estuary, there 
> is nearly universal agreement that marginal seas, including bays, are mapped 
> with the natural=coastline.
>
> Using the rendering at https://www.openstreetmap.de/karte.html - which 
> differentiates the marine water polygons outside of the coastline from lakes 
> and rivers, by using slightly different colors, we can see how bays are 
> mapped in other parts of North America and the world.
>
> For example, check out Delaware Bay, just up the coast from your area: 
> https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000
>  - it is mapped as a natural=bay with natural=coastline around it, not 
> natural=water
>
> Upper and Lower New York Bay are mapped as bays outside of the 
> natural=coastline - you can see the line where the waterway=riverbank area 
> starts just at the north end of Manhattan island (though this placement is 
> somewhat controversial) - 
> https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000
>
> Tampa Bay: 
> https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000
>  - outside of the natural=coastline
>
> Galveston Bay: 
> https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT
>  - outside of the natural=coastline
>
> San Francisco Bay and connected bays: 
> https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT
>  - outside of the coastline
>
> Puget Sound - while Lake Washington on the east side of Seattle is 
> natural=water, also most of the ship canal connecting them: 
> https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000
>
> I would like to request that the tidal channels and estuaries around 
> Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the 
> natural-water polygons for the estuaries that is not a problem.
>
> But it would be contrary to normal practice to map the main body of 
> Chesapeake Bay as natural=water because it is clearly part of the sea - there 
> is no barrier between it and the open ocean, since there is an open channel 
> through US 13 where the tunnel is. While it is an estuary by hydrological 
> definitions, so are the Baltic Sea and all fjords and Puget Sound and San 
> Francisco Bay - all of which are mapped as outside of the natural=coastline.
>
> Also please consider that the community here approved the proposal for 
> waterway=tidal_channel which said that the area of tidal channels (aka tidal 
> creeks) should be mapped with natural=coastline at their edges - see 
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dtidal_channel#How_to_Map 
> and 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel
>  - most of the "creek" features along the Bay are tidal channels.
>
> -- Joseph Eisenberg
>
> On Thu, Nov 19, 2020 at 6:46 AM Eric H. Christensen via Tagging 
>  wrote:
>
>> ‐‐‐ Original Message ‐‐‐
>>
>> On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano 
>>  wrote:
>>
>>> This was fascinating reading. I do agree that we ought to have a definition 
>>> for what gets tagged natural=coastline, and I think it's fine if that 
>>> definition has some subjectivity.
>>>
>>> I would offer something as simple as:
>>>
>>> "The coastline should follow the mean high tide line. In some cases this 
>>> rule would result in the coastline extending an unreasonable distance along 
>>> the banks of tidal rivers. In those cases, mappers should identify a 
>>> reasonable choke point at which to terminate the inland extent of coastline 
>>> tagging."
>>
>> I would just classify it as "where the ocean meets the land". Any other 
>> water that isn't ocean should be mapped as water and tagged appropriately. 
>> That makes the map more accurate and detailed.
>>
>> R,

Re: [Tagging] coastline v. water

[Joseph Eisenberg]

Eric,
I don't think the previous discussion is quite as inconclusive as your
evaluation.

While it is true that there is not widespread agreement on where the
natural=coatline ways should transect a river mouth or river estuary, there
is nearly universal agreement that marginal seas, including bays, are
mapped with the natural=coastline.

Using the rendering at https://www.openstreetmap.de/karte.html - which
differentiates the marine water polygons outside of the coastline from
lakes and rivers, by using slightly different colors, we can see how bays
are mapped in other parts of North America and the world.

For example, check out Delaware Bay, just up the coast from your area:
https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000
-
it is mapped as a natural=bay with natural=coastline around it, not
natural=water

Upper and Lower New York Bay are mapped as bays outside of the
natural=coastline - you can see the line where the waterway=riverbank area
starts just at the north end of Manhattan island (though this placement is
somewhat controversial) -
https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000

Tampa Bay:
https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000
- outside of the natural=coastline

Galveston Bay:
https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT
- outside of the natural=coastline

San Francisco Bay and connected bays:
https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT
- outside of the coastline

Puget Sound - while Lake Washington on the east side of Seattle is
natural=water, also most of the ship canal connecting them:
https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000

I would like to request that the tidal channels and estuaries around
Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the
natural-water polygons for the estuaries that is not a problem.

But it would be contrary to normal practice to map the main body of
Chesapeake Bay as natural=water because it is clearly part of the sea -
there is no barrier between it and the open ocean, since there is an open
channel through US 13 where the tunnel is. While it is an estuary by
hydrological definitions, so are the Baltic Sea and all fjords and Puget
Sound and San Francisco Bay - all of which are mapped as outside of the
natural=coastline.

Also please consider that the community here approved the proposal for
waterway=tidal_channel which said that the area of tidal channels (aka
tidal creeks) should be mapped with natural=coastline at their edges - see
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dtidal_channel#How_to_Map
and
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel
- most of the "creek" features along the Bay are tidal channels.

-- Joseph Eisenberg

On Thu, Nov 19, 2020 at 6:46 AM Eric H. Christensen via Tagging <
tagging@openstreetmap.org> wrote:

> ‐‐‐ Original Message ‐‐‐
>
> On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano <
> zelonew...@gmail.com> wrote:
>
> > This was fascinating reading.  I do agree that we ought to have a
> definition for what gets tagged natural=coastline, and I think it's fine if
> that definition has some subjectivity.
> >
> > I would offer something as simple as:
> >
> > "The coastline should follow the mean high tide line.  In some cases
> this rule would result in the coastline extending an unreasonable distance
> along the banks of tidal rivers.  In those cases, mappers should identify a
> reasonable choke point at which to terminate the inland extent of coastline
> tagging."
>
> I would just classify it as "where the ocean meets the land".  Any other
> water that isn't ocean should be mapped as water and tagged appropriately.
> That makes the map more accurate and detailed.
>
> R,
> Eric
>
> ___
> 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] surface=rock

[Tobias Zwick]

> rock „pieces“ would be tagged as „stone“ I guess?

Not so sure about that, then it would be surface=stones, (note the 
plural) wouldn't it?


---

There is a huge discussion on the #tagging channel on OSM slack (85+ 
replies) where all those "rocky" surface are being discussed.


Here are some statements from this discussion, also on the difference 
between "surface=rock" and "surface=stone". Most from Brian Sperlongano 
and Elliott Plack:


- Rock implies a rough naturalness

- Steps made of large (single-piece) hewn stone columns would be called 
'stone steps'


- Bare [rock] implies the lack of rubble on top

- Scree is specially loose

- Personally I think bare_rock and stone are synonyms here, unless 
someone thinks there's a difference.


- bare_rock has 569 usages, rock has 2759 usages and stone has 6402 
usages, scree has 319 usages, rocky has 1400 uses


---

For Germans, I'd say stone roughly translates to "Stein" while rock 
translates to "Fels". To summarize the above:


rock = rough natural stone, could be loose stones too
stone = smooth stone / bare rock, could be hewn
bare_rock = probably similar to stone, definitely no loose stones
scree = surface like (large) gravel, natural
rocky = scree is rocky, piles of differently sized rocks are rocky

Tobias

On 21/11/2020 09:57, Martin Koppenhoefer wrote:



sent from a phone


On 20. Nov 2020, at 23:22, Mateusz Konieczny via Tagging 
 wrote:

Both for exposed natural rock and steps/footways made of rock pieces?



rock „pieces“ would be tagged as „stone“ I guess?


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] surface=rock

[Martin Koppenhoefer]

sent from a phone

> On 20. Nov 2020, at 23:22, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Both for exposed natural rock and steps/footways made of rock pieces?


rock „pieces“ would be tagged as „stone“ I guess?


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