Re: [Tagging] How to tag a threshing floor

2020-11-06 Thread Jez Nicholson
I believe that a key point is that these threshing floors have protected
status in Portugal and Spain due to their historical significance. The
suggestion of using 'historic[al]' is to represent this.

In other parts of the world, where it is in current use and not
ancient/protected then perhaps it is an 'amenity'?

Is there a subtag to distinguish an historical/protected amenity from a
straight/unprotected one?


On Thu, 5 Nov 2020, 23:08 António Madeira via Tagging, <
tagging@openstreetmap.org> wrote:

> Yes, as I said in the previous message, it was my misunderstanding. Sorry
> about that.
>
>
> Às 20:02 de 05/11/2020, Mateusz Konieczny escreveu:
>
> I was referring to
>
> "
>
> I see there's a reference to this feature in this
> 
> wiki page, but wouldn't it fit better in the man_made tag? After all,
> this is still an used feature, although not always with the original intent.
>
> "
>
>
> Nov 5, 2020, 19:55 by tagging@openstreetmap.org:
>
> I didn't get it, Mateusz.
> What does historic=wayside_shrine have to do with threshing floor?
>
>
>
> On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>
> We also have historic=wayside_shrine that is used for ones that are not
> historic at all.
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - electricity=*

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 01:03 by elga...@agol.dk:

> Joseph Eisenberg:
>
>> Generally OpenStreetMap data is not updated frequently enough by mappers and 
>> database users for us to map temporary states (e.g. anything which lasts 
>> less than 6 months). Many database users will download a data extract for 
>> offline use and only update this every 3 months or so - see Maps.me for 
>> example, and perhaps facebook's  use of OpenStreetMap data.
>>
>
>
> I agree.
> But there are some interesting cases around that 6 month range.
>
> For example we now have access:covid19
>
>
> Another example is road work on motorways. That can easily take 6 month to a 
> year. First they do one side and have both directions share the lanes of what 
> was earlier one direction. Then they do the other side.
>
> Sometimes mappers change the speed limit to e.g. 60 km/h, but usually when 
> the work is finally done, it takes a long time for someone to put it back at 
> 130.
>
> It would be useful to be able to tag a temporary speed limit with an 
> estimated expiry date. And maybe an estimated start date for offline maps.
>
See https://wiki.openstreetmap.org/wiki/Conditional_restrictions

motor_vehicle:conditional=no @ (2018 May 22-2018 Oct 7)
maxspeed:conditional=60 @ (2021 May 22-2021 Oct 7)

This will self-terminate even if nobody will remember to remove tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag a threshing floor

2020-11-06 Thread Mateusz Konieczny via Tagging
heritage, heritage:operator, ref:??? appear to be used to tag official heritage 
status

See https://wiki.openstreetmap.org/wiki/Key:heritage


Nov 6, 2020, 09:26 by jez.nichol...@gmail.com:

> I believe that a key point is that these threshing floors have protected 
> status in Portugal and Spain due to their historical significance. The 
> suggestion of using 'historic[al]' is to represent this. 
>
> In other parts of the world, where it is in current use and not 
> ancient/protected then perhaps it is an 'amenity'?
>
> Is there a subtag to distinguish an historical/protected amenity from a 
> straight/unprotected one?
>
>
> On Thu, 5 Nov 2020, 23:08 António Madeira via Tagging, <> 
> tagging@openstreetmap.org> > wrote:
>
>> Yes, as I said in the previous message, it was my misunderstanding.Sorry 
>> about that.
>>  
>>  
>>  
>> Às 20:02 de 05/11/2020, Mateusz  Konieczny escreveu:
>>
>>> I was referring to
>>>
>>> "
>>> I see there's a reference to this feature in this<>>> 
>>> https://wiki.openstreetmap.org/wiki/Historical_Objects/Map_Properties>>> 
>>> >wiki page, but wouldn't it fit better in the man_made tag? After all,this 
>>> is still an used feature, although not always with the original intent.
>>> "
>>>
>>>
>>> Nov 5, 2020, 19:55 by >>> tagging@openstreetmap.org>>> :
>>>
 I didn't get it, Mateusz. 
 What does historic=wayside_shrine have to do with  threshing floor?




>>> On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via  
>>> Tagging <>>> tagging@openstreetmap.org>>> >  
>>> wrote:
>>>

 We also have historic=wayside_shrine that is
 used for ones that are not historic at all.

>>>
>>>
>>
>> ___
>>  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] How to tag a threshing floor

2020-11-06 Thread Martin Koppenhoefer
Am Do., 5. Nov. 2020 um 13:59 Uhr schrieb Paul Allen :

> This may be a losing battle but I'll point out (once again) that historic
> is not
> a synonym for old, disused or repurposed.
>


I agree, the word "historic" isn't always a synonymon for old , but the
things that we tag in "historic=*" are not necessarily "historic" in this
strict sense, they are objects of certain types that are generally seen to
fit well under the "historic" umbrella. We do not distinguish "truly
historic" wayshrines from "ordinary" wayshrines. And it is a question of
interpretation whether you consider an "ordinary" wayshrine to be historic
in the sense you are using it.




> It is for objects that are of
> historic interest
>


in the past century the focus of historians has widened, today there are
many of them who are interested in the general conditions and circumstances
of the society, much more than looking only at single impactful events or
acting
 persons. Anything can become of historic interest, it depends how you
integrate it in the tale ;-)



- not just old (how old is old, anyway?) but which are
> in some way historically noteworthy.
>


again, I understand what you are after, and I reject that this is a
requirement for things that are tagged with historic=*




> A threshing floor where a
> general planned a decisive battle might be of historic interest, an
> old threshing floor where nothing ever happened but threshing probably
> isn't.
>


it will be a testimony of historic agrarian production processes and
conditions, in any case.

To me it doesn't make sense to draw a line, dividing the same objects
having more or less historic value. If there is something to distinguish at
all, my suggestion would be to add a qualifier to those objects of
exceptional historical value (if this is verifiable).

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


Re: [Tagging] How to tag a threshing floor

2020-11-06 Thread Paul Allen
On Fri, 6 Nov 2020 at 08:41, Jez Nicholson  wrote:

>
> Is there a subtag to distinguish an historical/protected amenity from a
> straight/unprotected one?
>

heritage=* and associated tags.

For Portugal, see https://wiki.openstreetmap.org/wiki/Key:heritage#Portugal

For Spain, see https://wiki.openstreetmap.org/wiki/Key:heritage#Spain

heritage=* and historic=* are handled specially by the Historic Place map.
See, for example,
http://gk.historic.place/historische_objekte/l/en/index.html?zoom=13&lat=40.13318&lon=-8.84788&detail=3&select=n7098422115&pid=HaHbHcSaHe

Note also that historic=* and heritage=* are independent.  A historic item
may not be protected and a protected item may not be historic, or the
item may be both.

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


Re: [Tagging] How to tag a threshing floor

2020-11-06 Thread Paul Allen
On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer 
wrote:

> Am Do., 5. Nov. 2020 um 13:59 Uhr schrieb Paul Allen :
>
>> This may be a losing battle but I'll point out (once again) that historic
>> is not
>> a synonym for old, disused or repurposed.
>>
>
> I agree, the word "historic" isn't always a synonymon for old , but the
> things that we tag in "historic=*" are not necessarily "historic" in this
> strict sense, they are objects of certain types that are generally seen to
> fit well under the "historic" umbrella.
>

The wiki page gives guidelines as to what counts as historic.


> We do not distinguish "truly historic" wayshrines from "ordinary"
> wayshrines.
>

We currently do not make the distinction because we lack the tagging to
do so.  That is not an argument for not making a distinction.

>
> It is for objects that are of
>> historic interest
>>
>
>
> in the past century the focus of historians has widened, today there are
> many of them who are interested in the general conditions and circumstances
> of the society, much more than looking only at single impactful events or
> acting persons.
>

If we open the scope that widely then we include everything, which is not
useful.

Anything can become of historic interest, it depends how you integrate it
> in the tale ;-)
>

Here are some of the criteria I use:

1) Is there a plaque?  The plaque itself is historic=memorial, even if
it was installed yesterday.  The POI the plaque refers to may also
count as historic=*.

2) Is the POI in guidebooks or tourist information as being where a
significant historic event took place?

3) Many old fortifications, such as castles.

Those aren't comprehensive rules.  I might map something that doesn't
fit them.  I might not map something that does fit them.  They're just
the rules of thumb I apply.

- not just old (how old is old, anyway?) but which are
> in some way historically noteworthy.
>


>
> A threshing floor where a
>> general planned a decisive battle might be of historic interest, an
>> old threshing floor where nothing ever happened but threshing probably
>> isn't.
>>
>
> it will be a testimony of historic agrarian production processes and
> conditions, in any case.
>

As has since been revealed, these threshing floors are protected by a
heritage
organization for that reason.  They aren't historic, though, not unless
something
significant happened there.  The toilet in my house is around 15 years old
and
is a testimony to my bowel movements, but I do not consider it historic.
The
toilet Elvis died on, however...


> To me it doesn't make sense to draw a line, dividing the same objects
> having more or less historic value. If there is something to distinguish at
> all, my suggestion would be to add a qualifier to those objects of
> exceptional historical value (if this is verifiable).
>

We have a way of tagging objects of exceptional historical value, it's
historic=*.  Objects of unexceptional historical value, or of no historical
value do not get tagged with historic=*.  That's because historic is
not a synonym (in the real world or in tagging) for old, disused or
repurposed.

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


Re: [Tagging] What is a saltbox?

2020-11-06 Thread Mateusz Konieczny via Tagging

Feb 12, 2020, 20:39 by o...@lepiller.eu:

> Le 12 février 2020 14:26:26 GMT-05:00, Michael Brandtner via Tagging 
>  a écrit :
> >Hi,
> >we have a big inconsistency between different wiki pages and editors
> >how we define the roof shape "saltbox". 
> >1) A saltbox is a roof with a tilted part at left and right side and a
> >flat part on top. This definition can be found at:
> >https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
> >It is used for example in the presets of the Vespucci editor. 
>
>>
>>
> >2) A saltbox is a roof with only one tilted part (usually directed at
> >the road) and one flat part on top. On the other side it goes straight
> >down. The roof shape described at 1) is a double_saltbox.
> >This definition can be found
> >at:https://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table
>
>>
>>
> >This definition is for example used by the StreetComplete editor.
>
>>
>>
> >This is a serious issue, because it means that for none of the over
> >3,000 buildings with the tag roof:shape=saltbox we can know which shape
> >it actually has.
>
>>
>>
> >Cheers,Michael
>
> Also for some reason, this tag is different from what wikipedia describes a 
> saltbox to be: > https://en.wikipedia.org/wiki/Saltbox_house
>
I edited https://wiki.openstreetmap.org/wiki/Template:Roof:shape to note the 
problem
what is visible on https://wiki.openstreetmap.org/wiki/Key:roof:shape
and https://wiki.openstreetmap.org/wiki/Simple_3D_buildings

If someone cares about roof:shape values the best solution would be to propose 
new
values for involved shaped and deprecate saltbox value.

 (I am certainly not going to do this, may TODO list is far too long to do this
even if I would live until AD 2650).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Basic cartography features missing, why?

2020-11-06 Thread Anders Torger

Hello everyone, newcomer here!

I've been a casual contributing mapper for a couple of years here in 
Sweden. Only since 2018 :-O, I thought it was longer, and during this 
time I've made 1700 edits mostly using iD, just started using JOSM for 
some more complex edits. Anyway, I recently tried to up my game to make 
really high quality and "complete" maps in the areas I live. I have a 
lot of local knowledge combined with very high quality government maps 
(already preloaded into the editor, not the highest resolution version, 
but enough for most aspects) together with satellite images which today 
has much better alignment than a few years ago (still government maps 
are best on that). So good reference is there too, I have all I need to 
make a good job.


My areas are bit more rural, more nature. Villages, hamlets and towns. 
Nature is prominent and naming nature is important, many old names but 
still in active use by forestry, outdoor people, hunters and locals. 
When mapping these, I immediately run into basic issues that I'm 
surprised that they aren't solved already.


I'm not 100% sure if this mailing list is the right venue for discussing 
these issues. OSM as a community is quite hard to grasp for a newcomer 
and I have been sent to different places, but now I'm here.


Anyway, my observations (mostly using the default openstreetmap-carto 
style) :


** Tagging bays and straits as areas work great, as the renderer gets 
and idea how prominent it is and it can make proper text sizing and they 
can be seen even if zoomed out if the area is large. Lots of our lakes, 
even quite small ones have sub-naming, and with these features I can 
make really good mapping of this.


** Tagging and naming areas on ground does not seem to be developed much 
at all, unfortunately.


** There is natural=peninsula so one can tag and name an area of varying 
size, but it doesn't seem to render (unless I've made some mistake...)


** I can't make an area to name hills or slopes, which is very common 
around here (natural=hill would be nice and is more generic than slope). 
There's peak, but that's only for point for the highest peak with 
elevation, so it doesn't the purpose here.


** Valleys can only be tagged as ways, but here it would make much more 
sense to make an area, as sizes of these valleys vary a lot, and the 
renderer need to know how large this is (not just how long) to make sane 
renders.


** Due to limitations in area-based name tagging the map looks empty 
just when zoomed out a little, as names disappear almost directly, so 
despite detailed mapping and tagging the overview map is not as useful 
as it could be. While the renderer can and does make proper decisions of 
prominence for bays and strait made as areas, point-based natural names 
often yield strange and misleading maps as vastly different sized areas 
have just a point for the name and no other differentiator, there's no 
way the renderer can make an appropriate render decision as the data is 
not there.


** Support for group naming is limited. It's here very common that 
several smaller islands are named as a group, smaller ponds are named as 
a group etc, without having individual names. There are tags for that 
(group/cluster), but not rendered. The best alternative today is to make 
it a named multipolygon, but only few renderers make the expected 
result, ie one name rather than only in one subarea or duplicated in all 
areas (which looks strange as the name is often in plural form, or it 
doesn't show up at all if each subarea is small).


** Another fairly common group naming concept is when each feature has 
its own name, but the group of features have also a separate collective 
name. Maps supporting this concept will thus when you zoom out not show 
the individual names but only the group name. The group/cluster tag 
would perhaps be the way to do this, but as far as I know no current 
style supports it.


** As a minor note, I've noted there is no good tag for anonymous gravel 
yards, which there are a lot of here. Abandoned quarry is the closest, 
but still not right, as only some actually were gravel/sand pits to 
start with. Those gravel yards are often leftovers from construction 
work or forestry often even locals don't exactly know when or why they 
were made. Today they are used mainly used for parking by people being 
out in nature, but they are not maintained so they are not exactly 
parking lots either.


The central issue here is about naming though, support for group naming 
and the ability to name areas on land which just like bays and straits 
have fuzzy borders (there is no exact start or end of a hill or a 
valley). There is no question about it that the naming I mentioned above 
exist plentiful at least in Sweden, and it's used in Swedish 
general-purpose maps, it's not some special odd feature.


To me, which know very little about OSM and its history, but am used to 
using maps both in digital and paper f

Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Andrew Harvey
All great points there, I've ran into many of those myself. If you're
interested in helping work on solutions to these, discussion here is
probably the best place to start, once ideas gain some momentum you can
start a tagging proposal
https://wiki.openstreetmap.org/wiki/Proposal_process. Going through that
process takes a huge amount of time, effort and communication, but usually
results in well rounded documentation and considers a wide range of
scenarios and creates better tags than just "using whatever tags you like".
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Seth Deegan
A gravel area tag/tagging convention is needed. One use I’ve seen is
highways in particular seem to have gravel separator between the actual
road and usually grass. Standardizing a area (a way) with just the
surface=gravel tag could work.

El El vie, nov. 6, 2020 a la(s) 12:34, Anders Torger 
escribió:

> Hello everyone, newcomer here!
>
> I've been a casual contributing mapper for a couple of years here in
> Sweden. Only since 2018 :-O, I thought it was longer, and during this
> time I've made 1700 edits mostly using iD, just started using JOSM for
> some more complex edits. Anyway, I recently tried to up my game to make
> really high quality and "complete" maps in the areas I live. I have a
> lot of local knowledge combined with very high quality government maps
> (already preloaded into the editor, not the highest resolution version,
> but enough for most aspects) together with satellite images which today
> has much better alignment than a few years ago (still government maps
> are best on that). So good reference is there too, I have all I need to
> make a good job.
>
> My areas are bit more rural, more nature. Villages, hamlets and towns.
> Nature is prominent and naming nature is important, many old names but
> still in active use by forestry, outdoor people, hunters and locals.
> When mapping these, I immediately run into basic issues that I'm
> surprised that they aren't solved already.
>
> I'm not 100% sure if this mailing list is the right venue for discussing
> these issues. OSM as a community is quite hard to grasp for a newcomer
> and I have been sent to different places, but now I'm here.
>
> Anyway, my observations (mostly using the default openstreetmap-carto
> style) :
>
> ** Tagging bays and straits as areas work great, as the renderer gets
> and idea how prominent it is and it can make proper text sizing and they
> can be seen even if zoomed out if the area is large. Lots of our lakes,
> even quite small ones have sub-naming, and with these features I can
> make really good mapping of this.
>
> ** Tagging and naming areas on ground does not seem to be developed much
> at all, unfortunately.
>
> ** There is natural=peninsula so one can tag and name an area of varying
> size, but it doesn't seem to render (unless I've made some mistake...)
>
> ** I can't make an area to name hills or slopes, which is very common
> around here (natural=hill would be nice and is more generic than slope).
> There's peak, but that's only for point for the highest peak with
> elevation, so it doesn't the purpose here.
>
> ** Valleys can only be tagged as ways, but here it would make much more
> sense to make an area, as sizes of these valleys vary a lot, and the
> renderer need to know how large this is (not just how long) to make sane
> renders.
>
> ** Due to limitations in area-based name tagging the map looks empty
> just when zoomed out a little, as names disappear almost directly, so
> despite detailed mapping and tagging the overview map is not as useful
> as it could be. While the renderer can and does make proper decisions of
> prominence for bays and strait made as areas, point-based natural names
> often yield strange and misleading maps as vastly different sized areas
> have just a point for the name and no other differentiator, there's no
> way the renderer can make an appropriate render decision as the data is
> not there.
>
> ** Support for group naming is limited. It's here very common that
> several smaller islands are named as a group, smaller ponds are named as
> a group etc, without having individual names. There are tags for that
> (group/cluster), but not rendered. The best alternative today is to make
> it a named multipolygon, but only few renderers make the expected
> result, ie one name rather than only in one subarea or duplicated in all
> areas (which looks strange as the name is often in plural form, or it
> doesn't show up at all if each subarea is small).
>
> ** Another fairly common group naming concept is when each feature has
> its own name, but the group of features have also a separate collective
> name. Maps supporting this concept will thus when you zoom out not show
> the individual names but only the group name. The group/cluster tag
> would perhaps be the way to do this, but as far as I know no current
> style supports it.
>
> ** As a minor note, I've noted there is no good tag for anonymous gravel
> yards, which there are a lot of here. Abandoned quarry is the closest,
> but still not right, as only some actually were gravel/sand pits to
> start with. Those gravel yards are often leftovers from construction
> work or forestry often even locals don't exactly know when or why they
> were made. Today they are used mainly used for parking by people being
> out in nature, but they are not maintained so they are not exactly
> parking lots either.
>
> The central issue here is about naming though, support for group naming
> and the ability to name areas on land which just like

Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 19:31 by and...@torger.se:

> Hello everyone, newcomer here!
>
> I've been a casual contributing mapper for a couple of years here in Sweden. 
> Only since 2018 :-O, I thought it was longer, and during this time I've made 
> 1700 edits mostly using iD, just started using JOSM for some more complex 
> edits. Anyway, I recently tried to up my game to make really high quality and 
> "complete" maps in the areas I live. 
>
Hello! This type "lets completely do XYZ" tends to reveal 
unfinished/missing/problematic parts.

I hope that my answers will explain a bit situation and at least partially 
answer your questions.

> I'm not 100% sure if this mailing list is the right venue for discussing 
> these issues. 
>
It sounds that most of that is about tagging so I would say "yes"

> ** Tagging and naming areas on ground does not seem to be developed much at 
> all, unfortunately.
>


> ** There is natural=peninsula so one can tag and name an area of varying 
> size, but it doesn't seem to render (unless I've made some mistake...)
>
With less than 1000 mapped lack of support is not surprising. Not sure is there 
a better tag/way
to map this. If not, then simply mapping more of them is a good idea.

https://taginfo.openstreetmap.org/tags/natural=peninsula


> ** I can't make an area to name hills or slopes, which is very common around 
> here (natural=hill would be nice and is more generic than slope). There's 
> peak, but that's only for point for the highest peak with elevation, so it 
> doesn't the purpose here.
>
Using natural=peak for hill should be fine.

For slopes: is it name for part of slope? Farmland area on it? Entire hill? 
Something else?

I used for example https://www.openstreetmap.org/way/259975428 - I was lucky
as name applies just to farmland area.

> ** Valleys can only be tagged as ways, but here it would make much more sense 
> to make an area, as sizes of these valleys vary a lot, and the renderer need 
> to know how large this is (not just how long) to make sane renders.
>
You can tag valleys as areas. Are you maybe using iD (in-browser editor)? 

Note that iD has its own presets suitable for newbies, but it is perfectly fine 
to use
tagging schemes not included in iD.

(note: some people have developed strong opinions how bays, valleys etc should 
be tagged)

>
> ** Due to limitations in area-based name tagging the map looks empty just 
> when zoomed out a little, as names disappear almost directly, so despite 
> detailed mapping and tagging the overview map is not as useful as it could 
> be. 
>
Note that it depends on a renderer. It is possible to make smarter that will 
keep names for longer
if possible.

>
> While the renderer can and does make proper decisions of prominence for bays 
> and strait made as areas, point-based natural names often yield strange and 
> misleading maps as vastly different sized areas have just a point for the 
> name and no other differentiator, there's no way the renderer can make an 
> appropriate render decision as the data is not there.
>
What specific you have in mind? I admit that for example for peaks rendering is 
often poor,
but data for local importance (elevation) is there. But making automatic smart 
renderer is
tricky at best.

> ** Support for group naming is limited. It's here very common that several 
> smaller islands are named as a group, smaller ponds are named as a group etc, 
> without having individual names. There are tags for that (group/cluster), but 
> not rendered. 
>
Mostly because multipolygons are strictly superior.

> The best alternative today is to make it a named multipolygon, but only few 
> renderers make the expected result, ie one name rather than only in one 
> subarea or duplicated in all areas (which looks strange as the name is often 
> in plural form, or it doesn't show up at all if each subarea is small).
>
This is basically on the renderer side, I am unsure what can be improved here 
on data side.

> ** Another fairly common group naming concept is when each feature has its 
> own name, but the group of features have also a separate collective name. 
> Maps supporting this concept will thus when you zoom out not show the 
> individual names but only the group name. The group/cluster tag would perhaps 
> be the way to do this, but as far as I know no current style supports it.
>
Yes, this one is unsolved.

> ** As a minor note, I've noted there is no good tag for anonymous gravel 
> yards, which there are a lot of here. Abandoned quarry is the closest, but 
> still not right, as only some actually were gravel/sand pits to start with. 
> Those gravel yards are often leftovers from construction work or forestry 
> often even locals don't exactly know when or why they were made. Today they 
> are used mainly used for parking by people being out in nature, but they are 
> not maintained so they are not exactly parking lots either.
>
I would make a new separate thread for that and link some pictures because

Re: [Tagging] How to tag a threshing floor

2020-11-06 Thread António Madeira via Tagging

This is not correct. Threshing floors do not have protected status in
Portugal. There are some that are included in open air museums and maybe
in archaelogical sites, but there are thousands all over the country and
only maybe 10 or 20 are "protected".
As I said, they're still used, although rarely with the original intent.

Here's a proposal on how to map these features, from the Portuguese
mailing list:
*
man_made=threshing_floor*
   (**) "man_made" is mandatory
https://en.wikipedia.org/wiki/Threshing_floor

*historic=threshing_floor
*
   (***) "historic" is optional, but *highly recommended*, if
"historic" is relevant
https://taghistory.raifer.tech/#***/historic/threshing_floor

*surface=paving_stones*|*
   ()  optional, any value admissible for tag "surface"
https://wiki.openstreetmap.org/wiki/Key:surface

*access=yes|no|private*
   (*) optional, any value admissible for tag "access"
https://wiki.openstreetmap.org/wiki/Key:access#List_of_possible_values



Às 05:26 de 06/11/2020, Jez Nicholson escreveu:

I believe that a key point is that these threshing floors have
protected status in Portugal and Spain due to their historical
significance. The suggestion of using 'historic[al]' is to represent
this.

In other parts of the world, where it is in current use and not
ancient/protected then perhaps it is an 'amenity'?

Is there a subtag to distinguish an historical/protected amenity from
a straight/unprotected one?


On Thu, 5 Nov 2020, 23:08 António Madeira via Tagging,
mailto:tagging@openstreetmap.org>> wrote:

Yes, as I said in the previous message, it was my
misunderstanding. Sorry about that.


Às 20:02 de 05/11/2020, Mateusz Konieczny escreveu:

I was referring to

"
I see there's a reference to this feature in this

wiki page, but wouldn't it fit better in the man_made tag? After all,
this is still an used feature, although not always with the original intent.
"


Nov 5, 2020, 19:55 by tagging@openstreetmap.org
:

I didn't get it, Mateusz.
What does historic=wayside_shrine have to do with threshing
floor?




On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via
Tagging mailto:tagging@openstreetmap.org>> wrote:


We also have historic=wayside_shrine that is
used for ones that are not historic at all.





___
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] How to tag a threshing floor

2020-11-06 Thread Martin Koppenhoefer
Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen :

> On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer 
> wrote:
>
>> We do not distinguish "truly historic" wayshrines from "ordinary"
>> wayshrines.
>>
>
> We currently do not make the distinction because we lack the tagging to
> do so.  That is not an argument for not making a distinction.
>


right. But given that we have not done it so far through the historic key,
the sustainable way is not by redefining the meaning of a key that is
already used more than a million times.



...
>
> To me it doesn't make sense to draw a line, dividing the same objects
> having more or less historic value. If there is something to distinguish at
> all, my suggestion would be to add a qualifier to those objects of
> exceptional historical value (if this is verifiable).
>

We have a way of tagging objects of exceptional historical value, it's
historic=*.  Objects of unexceptional historical value, or of no historical
value do not get tagged with historic=*.  That's because historic is
not a synonym (in the real world or in tagging) for old, disused or
repurposed.


just that it is not what we are currently doing.

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Anders Torger

I'd love to help out if the workload and chance of success was
reasonable, but I'm a bit wary about the tagging proposal process. Most
of my mapping contributions is simple things like correcting and adding
roads so all the various online route planners (and indeed bike
computers) that use OSM in one way or another can work in the areas I
spend time. For that the map does not need to be complete at all, I just
need a graph of roads, and I use the regular government-provided maps to
actually scout the area. 


Recently I got more interested in trying to make actual complete and
good cartography, make maps that accurately describes the area (to a
certain detail level) and doesn't require "a real map" on the side for
scouting, in other words make OSM to be a real map in the areas I live.
It would also be nice if one could make hiking maps for the mountains.
This is an extremely ambitious goal, in Scandinavia, and probably many
more countries, we are used at having really great cartography from a
special cartography institute which is a part of the government.
Previously the maps were expensive to get and you could only get it on
paper. Today the main aspects exists for free in digital form (which is
a good thing, it's made with tax payers' money after all). Here, this is
the gold standard for a general-purpose map. 


However, when I see there are some key features missing in OSM to be
able to reach that level, and each of those little features may take
years of processing from proposal to actual implementation in a renderer
(and even if a proposal goes through, I suppose it's not guaranteed that
it may be implemented), then it feels like it's just too much for me, as
I'm involved in many other volunteer projects too. Mapping is not even
my main project. 


To make this happen it seems like I will end up with having to implement
my own style and have my own tile server and using my own tags... it's
just not feasible. What I have done so far in my own mapping
applications which works sort of fine is to use ready-made government
maps in a custom layer for the more zoomed out map (and indeed have an
own tile server for that), and then switch to OSM for the most zoomed in
levels. The limitations in name handling and missing names for large
areas is less noticed when fully zoomed in. But it would be really cool
if one could use OSM for the whole cartography experience. 


As far as I understand, OSM is supposed to be a decentralized and
semi-anarchistic consensus community that's why the proposal process
looks like it does, but somehow I was hoping for that there was a
strategic work group with access to professional cartography expertise
that on their own could recognize, pick up, and implement both the
feature and the guideline for baseline type of "must have" features,
while tagging proposal process would be for more exotic things. 


I'm afraid that with this thorough long-haul process and still pretty
basic cartography features lacking, we may never see them. I understand
that OSM is a geo database, not a map as such, and it seems like the
actual map-making hasn't been a top priority but left to third parties,
and this may be a reason that features required for top quality
cartography has been left unimplemented for so long. 


Another thing with these naming features is while they are indeed
important to reach professional-grade maps, you need to be a very
patient and persistent perfectionist to actually care (sort of like an
old-school cartographer), and have the endurance to continue to care.
It's much easier to just skip the names that can't be mapped, or make
them as a point and not care that zoomed out maps don't work well. We've
seen plenty of desperate/chaotic use of place=locality tag just to get
names when there is no real support.

If that's the case, then it maybe is better to just relax, let go, and
let OSM be what it is today and not try achieve what it can't do. For me
this means going back to just doing road work, and switch to the
government maps anytime I need a real map. I'm fine with that. 


On 2020-11-06 20:19, Andrew Harvey wrote:

All great points there, I've ran into many of those myself. If you're interested in helping work on solutions to these, discussion here is probably the best place to start, once ideas gain some momentum you can start a tagging proposal https://wiki.openstreetmap.org/wiki/Proposal_process. Going through that process takes a huge amount of time, effort and communication, but usually results in well rounded documentation and considers a wide range of scenarios and creates better tags than just "using whatever tags you like". 
___

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] Basic cartography features missing, why?

2020-11-06 Thread Martin Koppenhoefer
Am Fr., 6. Nov. 2020 um 21:04 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> ** Support for group naming is limited. It's here very common that several
> smaller islands are named as a group, smaller ponds are named as a group
> etc, without having individual names. There are tags for that
> (group/cluster), but not rendered.
>
> Mostly because multipolygons are strictly superior.
>


for groups, the group relation is clearly superior. First of all, it
implies group semantics and is defined. For a multipolygon, it may not be
clear what it is about, unless you invent tags for "a group of lakes", a
group of ponds, a group of trees, a group of island. But still, it only
works for areas, you cannot use multipolygons for groups of nodes or groups
of lines, or mixes of these.

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Anders Torger

Sorry for replying to myself, but I forgot to mention one important
aspect that I myself hadn't realized until recently: it's seems to be a
whole lot about processing power too. 


Name tag scaling and placement strategies are expensive algorithms
compared to what we the default style does now, and I see repeatedly
when various improvements to openstreetmap-carto is discussed that "the
idea is good and would improve the style, but is unfortunately too
computationally expensive so it's not feasible". I suspect that least
some of the naming falls into that category, especially when doing smart
things when zooming out to give good overview maps. 


I have not understood why there are these CPU limits, if it's "just" due
to under-financed server infrastructure, or if it is a problem that
can't be solved regardless of server infrastructure. As a layman one
would think that some of these algorithms could run on GPU clusters
these days, but I have no idea... it feels a bit problematic though if
the quality of OSM's cartography is held back due to limited server
infrastructure. 

/Anders 


On 2020-11-06 22:51, Anders Torger wrote:

I'd love to help out if the workload and chance of success was reasonable, but I'm a bit wary about the tagging proposal process. Most of my mapping contributions is simple things like correcting and adding roads so all the various online route planners (and indeed bike computers) that use OSM in one way or another can work in the areas I spend time. For that the map does not need to be complete at all, I just need a graph of roads, and I use the regular government-provided maps to actually scout the area. 

Recently I got more interested in trying to make actual complete and good cartography, make maps that accurately describes the area (to a certain detail level) and doesn't require "a real map" on the side for scouting, in other words make OSM to be a real map in the areas I live. It would also be nice if one could make hiking maps for the mountains. This is an extremely ambitious goal, in Scandinavia, and probably many more countries, we are used at having really great cartography from a special cartography institute which is a part of the government. Previously the maps were expensive to get and you could only get it on paper. Today the main aspects exists for free in digital form (which is a good thing, it's made with tax payers' money after all). Here, this is the gold standard for a general-purpose map. 

However, when I see there are some key features missing in OSM to be able to reach that level, and each of those little features may take years of processing from proposal to actual implementation in a renderer (and even if a proposal goes through, I suppose it's not guaranteed that it may be implemented), then it feels like it's just too much for me, as I'm involved in many other volunteer projects too. Mapping is not even my main project. 

To make this happen it seems like I will end up with having to implement my own style and have my own tile server and using my own tags... it's just not feasible. What I have done so far in my own mapping applications which works sort of fine is to use ready-made government maps in a custom layer for the more zoomed out map (and indeed have an own tile server for that), and then switch to OSM for the most zoomed in levels. The limitations in name handling and missing names for large areas is less noticed when fully zoomed in. But it would be really cool if one could use OSM for the whole cartography experience. 

As far as I understand, OSM is supposed to be a decentralized and semi-anarchistic consensus community that's why the proposal process looks like it does, but somehow I was hoping for that there was a strategic work group with access to professional cartography expertise that on their own could recognize, pick up, and implement both the feature and the guideline for baseline type of "must have" features, while tagging proposal process would be for more exotic things. 

I'm afraid that with this thorough long-haul process and still pretty basic cartography features lacking, we may never see them. I understand that OSM is a geo database, not a map as such, and it seems like the actual map-making hasn't been a top priority but left to third parties, and this may be a reason that features required for top quality cartography has been left unimplemented for so long. 


Another thing with these naming features is while they are indeed important to 
reach professional-grade maps, you need to be a very patient and persistent 
perfectionist to actually care (sort of like an old-school cartographer), and 
have the endurance to continue to care. It's much easier to just skip the names 
that can't be mapped, or make them as a point and not care that zoomed out maps 
don't work well. We've seen plenty of desperate/chaotic use of place=locality 
tag just to get names when there is no real support.

If that's the case, then it maybe is better 

Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Graeme Fitzpatrick
On Sat, 7 Nov 2020 at 04:34, Anders Torger  wrote:

>
> ** Due to limitations in area-based name tagging the map looks empty
> just when zoomed out a little, as names disappear almost directly, so
> despite detailed mapping and tagging the overview map is not as useful
> as it could be. While the renderer can and does make proper decisions of
> prominence for bays and strait made as areas, point-based natural names
> often yield strange and misleading maps as vastly different sized areas
> have just a point for the name and no other differentiator, there's no
> way the renderer can make an appropriate render decision as the data is
> not there.
>

Welcome, Anders.

That is a problem that we encounter all the time in Australia, where there
are huge expanses of empty, & official OSM guidelines mean that not much
shows :-( Can be worked around to a certain extent by tagging for the
renderer by upping villages / hamlets to towns & making country roads
highway=trunk but officially not approved.

On Sat, 7 Nov 2020 at 05:31, Seth Deegan  wrote:

> A gravel area tag/tagging convention is needed. One use I’ve seen is
> highways in particular seem to have gravel separator between the actual
> road and usually grass. Standardizing a area (a way) with just the
> surface=gravel tag could work.
>
> El El vie, nov. 6, 2020 a la(s) 12:34, Anders Torger 
> escribió:
>
>>
>> ** As a minor note, I've noted there is no good tag for anonymous gravel
>> yards, which there are a lot of here. Abandoned quarry is the closest,
>> but still not right, as only some actually were gravel/sand pits to
>> start with. Those gravel yards are often leftovers from construction
>> work or forestry often even locals don't exactly know when or why they
>> were made. Today they are used mainly used for parking by people being
>> out in nature, but they are not maintained so they are not exactly
>> parking lots either.
>>
>
Assuming of course that we're talking about the same thing - areas on the
side of the road where gravel was dumped while road work was taking place?
eg
https://www.openstreetmap.org/edit?relation=6007743#map=19/-36.41030/148.59385
or
https://www.google.com.au/maps/@-28.169598,152.8911178,3a,27.7y,206.26h,88.62t/data=!3m6!1e1!3m4!1shrpfOqOyE4oBith4P7iQzQ!2e0!7i13312!8i6656?hl=en
(NB not the same spot! & G Maps used as an example only , not for mapping
blah, blah, blah ...)

These were discussed in the Australia list a little while ago:
https://lists.openstreetmap.org/pipermail/talk-au/2020-February/013632.html
with no real consensus but landuse=stockpile + resource=aggregate (gravel /
sand / rock etc) was fairly well received.

Unfortunately, though, that won't render :-(, although a counter suggestion
of landuse=industrial + industrial=stockpile + resource=*** would :-)

Good luck!

Thanks

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Anders Torger

I agree, but one renders (in some way at least), the other doesn't.
Which one will the casual mapper choose? I'm a bit impatient and like to
see results now. 


The cluster tag was drafted 2015, the group tag 2018. None of them
render as far as I know. 

/Anders 


On 2020-11-06 23:10, Martin Koppenhoefer wrote:

Am Fr., 6. Nov. 2020 um 21:04 Uhr schrieb Mateusz Konieczny via Tagging : 

** Support for group naming is limited. It's here very common that several smaller islands are named as a group, smaller ponds are named as a group etc, without having individual names. There are tags for that (group/cluster), but not rendered. 
Mostly because multipolygons are strictly superior.


for groups, the group relation is clearly superior. First of all, it
implies group semantics and is defined. For a multipolygon, it may not
be clear what it is about, unless you invent tags for "a group of
lakes", a group of ponds, a group of trees, a group of island. But
still, it only works for areas, you cannot use multipolygons for groups
of nodes or groups of lines, or mixes of these. 

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] Basic cartography features missing, why?

2020-11-06 Thread Martin Koppenhoefer
Am Fr., 6. Nov. 2020 um 23:21 Uhr schrieb Anders Torger :

> I have not understood why there are these CPU limits, if it's "just" due
> to under-financed server infrastructure, or if it is a problem that can't
> be solved regardless of server infrastructure. As a layman one would think
> that some of these algorithms could run on GPU clusters these days, but I
> have no idea... it feels a bit problematic though if the quality of OSM's
> cartography is held back due to limited server infrastructure.
>


if you want to create a map for publishing it, you can also do
computationally expensive tasks in the process, but if you are updating and
republishing continuously, every minute, you will want to reduce the
computational effort.

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


Re: [Tagging] How to tag a threshing floor

2020-11-06 Thread Paul Allen
On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer 
wrote:

> Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen :
>
>> On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer 
>> wrote:
>>
>> ...
>>
>> To me it doesn't make sense to draw a line, dividing the same objects
>>> having more or less historic value. If there is something to distinguish at
>>> all, my suggestion would be to add a qualifier to those objects of
>>> exceptional historical value (if this is verifiable).
>>>
>>
>> We have a way of tagging objects of exceptional historical value, it's
>> historic=*.  Objects of unexceptional historical value, or of no
>> historical
>> value do not get tagged with historic=*.  That's because historic is
>> not a synonym (in the real world or in tagging) for old, disused or
>> repurposed.
>>
>
> just that it is not what we are currently doing.
>
> That is not what some of us are currently doing.  Others read the wiki page
and tag accordingly.

It occurs to me that some of the mis-tagging (as I see it) and some of the
discussions here may revolve around semantics as interpreted by
those who do not have English as a first language.  There is a
difference between "historical" and "historic."

Historians are concerned with historical data.  Old data (about
populations, diseases or whatever) is historical data.  The
assassination of a minor archduke, which seemed unimportant
at the time, quickly turned into a historic event.

When somebody says that "historic" applies to everything that
historians do, that is incorrect.  What historians mostly do is
look at historical data, some small fraction of which is
also historic.

See https://www.grammarly.com/blog/historic-historical/
for a better explanation.

So historic=* really should only apply (as the wiki page states) to the
important
things of the past, not everything some random historian might happen
to be looking into.

So the question is, do we accept that because some mappers have misused
the tag we should encourage that misuse or do we discourage it?

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Martin Koppenhoefer
Am Fr., 6. Nov. 2020 um 23:28 Uhr schrieb Anders Torger :

> I agree, but one renders (in some way at least), the other doesn't. Which
> one will the casual mapper choose? I'm a bit impatient and like to see
> results now.
>
> The cluster tag was drafted 2015, the group tag 2018. None of them render
> as far as I know.
>


that's both not "old" in OSM. Almost all tags that are rendered currently
have been around for at least double that time. The more you use a feature,
the more likely it will eventually be implemented later on by data users.
Nobody is going to invent and test a system just to render 100 objects.

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Anders Torger

Good point, so there's a balance. However, how important is it that
update of the map is immediate for every database update? To me it seems
more desirable to have a higher quality cartography at the price of a
lower update rate. Longer tile generation times won't affect serving
rate, just how quickly you see your edits appear in the map, which by
the way seems to have improved significantly since I started mapping. 


You could argue, that the default style should focus on speed and
commercial third party providers can focus on quality. While I think
that argument has some merit, I see a problem as openstreetmap-carto is
the de-facto driver for general-purpose tagging. If basic cartography
features concerning naming for example doesn't appear on that or are
rendered poorly, mappers won't be motivated to tag properly for it. One
example is making a multipolygon instead of the semantically superior
group, as multipolygon actually renders. 

/Anders 


On 2020-11-06 23:26, Martin Koppenhoefer wrote:

Am Fr., 6. Nov. 2020 um 23:21 Uhr schrieb Anders Torger : 


I have not understood why there are these CPU limits, if it's "just" due to 
under-financed server infrastructure, or if it is a problem that can't be solved 
regardless of server infrastructure. As a layman one would think that some of these 
algorithms could run on GPU clusters these days, but I have no idea... it feels a bit 
problematic though if the quality of OSM's cartography is held back due to limited server 
infrastructure.


if you want to create a map for publishing it, you can also do computationally expensive tasks in the process, but if you are updating and republishing continuously, every minute, you will want to reduce the computational effort. 

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] Basic cartography features missing, why?

2020-11-06 Thread Anders Torger

On 2020-11-06 23:35, Martin Koppenhoefer wrote:

Am Fr., 6. Nov. 2020 um 23:28 Uhr schrieb Anders Torger : 

I agree, but one renders (in some way at least), the other doesn't. Which one will the casual mapper choose? I'm a bit impatient and like to see results now. 


The cluster tag was drafted 2015, the group tag 2018. None of them render as 
far as I know.


that's both not "old" in OSM. Almost all tags that are rendered currently have 
been around for at least double that time. The more you use a feature, the more likely it 
will eventually be implemented later on by data users. Nobody is going to invent and test 
a system just to render 100 objects.


And indeed we are closing in to the core of the problem. I don't think
the traditional OSM processes is keeping up with its own growth and the
speed the competition is moving. Some reform in the organization is
probably required at least in part, or else OSM is too stagnant for its
own good. 


If OSM had a strategic working group that were responsible for some key
developments in style and cartography they could on their own identify
baseline features that are lacking or that can be improved. Cartography
has been around for a very long time, long before computers. The naming
issues I've described is not actually new and unique. I think all of
them would have been picked up by such a strategic cartography group,
which would implement features and suggest guidelines. And this is not
really dictatorship either, if mappers won't use the features, so be it.
A misjudgment and some unused code. There's still a place for a long
term tagging process for more exotic things, but waiting many years for
basic features this process has for one reason or another missed up to
this point I think is a problem. 


If individual casual unorganized mappers like myself on their own shall
make these features happen and have 4 - 10 years patience to see it
maybe go through, it won't happen and the likelihood decreases the
larger the community becomes. It's not suistainable today. How will
Google Maps look in 4 - 10 years? AI and machine learning is coming. I
think we need to keep moving and keep upping our game or watch us become
irrelevant, at least in many countries. 


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


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Brian M. Sperlongano
Welcome!

If you do choose to go down the path of the proposal process, I would
potentially be willing to assist in the proposal drafting.  It is certainly
a bunch of work to get a proposal through, but it's hard because it's worth
doing.  I have a proposal in process now and a few others (hopefully) in
the pipeline.

https://wiki.openstreetmap.org/wiki/User:ZeLonewolf
-Brian

On Fri, Nov 6, 2020 at 4:53 PM Anders Torger  wrote:

> I'd love to help out if the workload and chance of success was reasonable,
> but I'm a bit wary about the tagging proposal process. Most of my mapping
> contributions is simple things like correcting and adding roads so all the
> various online route planners (and indeed bike computers) that use OSM in
> one way or another can work in the areas I spend time. For that the map
> does not need to be complete at all, I just need a graph of roads, and I
> use the regular government-provided maps to actually scout the area.
>
> Recently I got more interested in trying to make actual complete and good
> cartography, make maps that accurately describes the area (to a certain
> detail level) and doesn't require "a real map" on the side for scouting, in
> other words make OSM to be a real map in the areas I live. It would also be
> nice if one could make hiking maps for the mountains. This is an extremely
> ambitious goal, in Scandinavia, and probably many more countries, we are
> used at having really great cartography from a special cartography
> institute which is a part of the government. Previously the maps were
> expensive to get and you could only get it on paper. Today the main aspects
> exists for free in digital form (which is a good thing, it's made with tax
> payers' money after all). Here, this is the gold standard for a
> general-purpose map.
>
> However, when I see there are some key features missing in OSM to be able
> to reach that level, and each of those little features may take years of
> processing from proposal to actual implementation in a renderer (and even
> if a proposal goes through, I suppose it's not guaranteed that it may be
> implemented), then it feels like it's just too much for me, as I'm involved
> in many other volunteer projects too. Mapping is not even my main project.
>
> To make this happen it seems like I will end up with having to implement
> my own style and have my own tile server and using my own tags... it's just
> not feasible. What I have done so far in my own mapping applications which
> works sort of fine is to use ready-made government maps in a custom layer
> for the more zoomed out map (and indeed have an own tile server for that),
> and then switch to OSM for the most zoomed in levels. The limitations in
> name handling and missing names for large areas is less noticed when fully
> zoomed in. But it would be really cool if one could use OSM for the whole
> cartography experience.
>
> As far as I understand, OSM is supposed to be a decentralized and
> semi-anarchistic consensus community that's why the proposal process looks
> like it does, but somehow I was hoping for that there was a strategic work
> group with access to professional cartography expertise that on their own
> could recognize, pick up, and implement both the feature and the guideline
> for baseline type of "must have" features, while tagging proposal process
> would be for more exotic things.
>
> I'm afraid that with this thorough long-haul process and still pretty
> basic cartography features lacking, we may never see them. I understand
> that OSM is a geo database, not a map as such, and it seems like the actual
> map-making hasn't been a top priority but left to third parties, and this
> may be a reason that features required for top quality cartography has been
> left unimplemented for so long.
>
> Another thing with these naming features is while they are indeed
> important to reach professional-grade maps, you need to be a very patient
> and persistent perfectionist to actually care (sort of like an old-school
> cartographer), and have the endurance to continue to care. It's much easier
> to just skip the names that can't be mapped, or make them as a point and
> not care that zoomed out maps don't work well. We've seen plenty of
> desperate/chaotic use of place=locality tag just to get names when there is
> no real support.
>
> If that's the case, then it maybe is better to just relax, let go, and let
> OSM be what it is today and not try achieve what it can't do. For me this
> means going back to just doing road work, and switch to the government maps
> anytime I need a real map. I'm fine with that.
>
> On 2020-11-06 20:19, Andrew Harvey wrote:
>
> All great points there, I've ran into many of those myself. If you're
> interested in helping work on solutions to these, discussion here is
> probably the best place to start, once ideas gain some momentum you can
> start a tagging proposal
> https://wiki.openstreetmap.org/wiki/Proposal_process. Going through that
> p

Re: [Tagging] Feature Proposal - RFC - Rideshare Access

2020-11-06 Thread Clare Corthell via Tagging
Hi all,

Thanks for the discussion. Lately the open questions center on formulating
tags for pickup/dropoff points or areas as opposed to roads. Some of the
latest:
- How should a designated curb location be indicated for rideshare access?
How might this apply to a point or area (eg parking lot

)?
- How might designations for specific companies be indicated? (eg Uber
pickup location differing from Lyft pickup location)
- How might access for pickup only, dropoff only, or both be indicated? Do
existing access values satisfy these? Is a tag indicating pickup/dropoff
zone/point needed?
- How would an exclusive road for rideshare be tagged,
"rideshare=yes"+"access=no" or "rideshare=designated"+"access=no"?
- Is there a more common term for uber/grab/lyft/yandex/etc than
"rideshare"?

Please add to this summary or join in. Open to starting the voting process
~Nov 12, we could push back again if this begs further discussion.

Clare

On Wed, Nov 4, 2020 at 3:38 PM Andrew Harvey 
wrote:

> I wouldn't do that because then logically you have two features, but in
> this case they are one in the same, it's a rideshare pickup parking lot, as
> opposed to a on-street section designated for rideshare pickup/dropoff.
>
> On Thu, 5 Nov 2020 at 09:38, Simon Poole  wrote:
>
>> While I would try to avoid it, you can naturally simply duplicate the
>> geometry (and you don't even need to duplicate the nodes to do that).
>> Am 04.11.2020 um 22:26 schrieb Andrew Harvey:
>>
>>
>> On Wed, 4 Nov 2020 at 20:10, Philip Barnes  wrote:
>>
>>> On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
>>>
>>>
>>>
>>> On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:
>>>
>>> We don't seem to have a tagging currently for dedicated pickup locations
>>> in this kind of context, bus stops etc are naturally taggable), if
>>> considered really useful I don't see why we couldn't introduce a
>>> amenity=...pickup... tag.
>>>
>>>
>>> But if such a dedicated pickup location is a carpark then it needs
>>> amenity=parking, so it can't fit into the amenity key.
>>>
>>>
>>> A pickup point will be a node within a car park area.
>>>
>>> Its is already common to add amenity=bicycle_parking nodes within
>>> amenity=car_park areas.
>>>
>>
>> Why would it be a node within a car park? For example
>> https://www.openstreetmap.org/way/366754575 is the designated airport
>> Uber, etc. pickup location, not some point inside the car park, but the
>> whole car park itself.
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Clare Corthell
Product Manager, Lyft Mapping
*How Lyft Creates Hyper-Accurate Maps from Open-Source Maps and Real-Time
Data
*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Martin Søndergaard
  I am also very much a newcomer only having mapped for a few months, and
so far I have constantly been running into the same problems that
are mentioned in this thread.

I am mapping in Denmark where we have high quality official information on
place names. However, adding much of this information in OSM is very
difficult. In most cases the place names are *not* tied to a single
specific landuse or natural area. Here are a couple examples I have worked
on:

*Orebanker* - https://www.openstreetmap.org/way/861178572
This is a prominent bank or elongated hill with a single name. However, it
consists of a mix of landuse=forest and landuse=farmland and no obvious
single feature to add the name to. What is the correct way to tag this?

*Viemosen *- https://www.openstreetmap.org/way/863161581
This is the name of an area of wetland/meadow, but a part of the area has
been reclaimed for farmland. However, the name officially still applies to
the original area, so it should include the farmland just north of the
meadow. Instead I have had to just add the name to the only feature that
covers most of the area. You could argue that it is better than nothing,
but technically it is slightly incorrect information.

As a casual mapper mapping this information is really discouraging. Best
case, the names might show up on renders in 5-10 years; worst case, the lag
of standard guidelines on this means that the tagging is wrong or few
people add this information and renderers never render it.

I understand that tagging standards are based mostly on how many current
features with  said tag there are and it is therefore slow to change. And
this process makes some amount of sense for more specialized information.
But for something as basic as "*how do we tag the place name of an area
that is not tied to a single feature?*" it baffles me that there is no
consensus after 16 years. It is clearly a sign that the current process of
agreeing on tagging standards is not working in this specific case.

/Martin

On Fri, 6 Nov 2020 at 19:34, Anders Torger  wrote:

> Hello everyone, newcomer here!
>
> I've been a casual contributing mapper for a couple of years here in
> Sweden. Only since 2018 :-O, I thought it was longer, and during this
> time I've made 1700 edits mostly using iD, just started using JOSM for
> some more complex edits. Anyway, I recently tried to up my game to make
> really high quality and "complete" maps in the areas I live. I have a
> lot of local knowledge combined with very high quality government maps
> (already preloaded into the editor, not the highest resolution version,
> but enough for most aspects) together with satellite images which today
> has much better alignment than a few years ago (still government maps
> are best on that). So good reference is there too, I have all I need to
> make a good job.
>
> My areas are bit more rural, more nature. Villages, hamlets and towns.
> Nature is prominent and naming nature is important, many old names but
> still in active use by forestry, outdoor people, hunters and locals.
> When mapping these, I immediately run into basic issues that I'm
> surprised that they aren't solved already.
>
> I'm not 100% sure if this mailing list is the right venue for discussing
> these issues. OSM as a community is quite hard to grasp for a newcomer
> and I have been sent to different places, but now I'm here.
>
> Anyway, my observations (mostly using the default openstreetmap-carto
> style) :
>
> ** Tagging bays and straits as areas work great, as the renderer gets
> and idea how prominent it is and it can make proper text sizing and they
> can be seen even if zoomed out if the area is large. Lots of our lakes,
> even quite small ones have sub-naming, and with these features I can
> make really good mapping of this.
>
> ** Tagging and naming areas on ground does not seem to be developed much
> at all, unfortunately.
>
> ** There is natural=peninsula so one can tag and name an area of varying
> size, but it doesn't seem to render (unless I've made some mistake...)
>
> ** I can't make an area to name hills or slopes, which is very common
> around here (natural=hill would be nice and is more generic than slope).
> There's peak, but that's only for point for the highest peak with
> elevation, so it doesn't the purpose here.
>
> ** Valleys can only be tagged as ways, but here it would make much more
> sense to make an area, as sizes of these valleys vary a lot, and the
> renderer need to know how large this is (not just how long) to make sane
> renders.
>
> ** Due to limitations in area-based name tagging the map looks empty
> just when zoomed out a little, as names disappear almost directly, so
> despite detailed mapping and tagging the overview map is not as useful
> as it could be. While the renderer can and does make proper decisions of
> prominence for bays and strait made as areas, point-based natural names
> often yield strange and misleading maps as vastly different sized areas
> h

Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Andrew Harvey
The documented tag for that is place=locality, an in populated named place.
it's rendered and in Nomatnium.

On Sat, 7 Nov 2020, 12:44 pm Martin Søndergaard, 
wrote:

>   I am also very much a newcomer only having mapped for a few months, and
> so far I have constantly been running into the same problems that
> are mentioned in this thread.
>
> I am mapping in Denmark where we have high quality official information on
> place names. However, adding much of this information in OSM is very
> difficult. In most cases the place names are *not* tied to a single
> specific landuse or natural area. Here are a couple examples I have worked
> on:
>
> *Orebanker* - https://www.openstreetmap.org/way/861178572
> This is a prominent bank or elongated hill with a single name. However, it
> consists of a mix of landuse=forest and landuse=farmland and no obvious
> single feature to add the name to. What is the correct way to tag this?
>
> *Viemosen *- https://www.openstreetmap.org/way/863161581
> This is the name of an area of wetland/meadow, but a part of the area has
> been reclaimed for farmland. However, the name officially still applies to
> the original area, so it should include the farmland just north of the
> meadow. Instead I have had to just add the name to the only feature that
> covers most of the area. You could argue that it is better than nothing,
> but technically it is slightly incorrect information.
>
> As a casual mapper mapping this information is really discouraging. Best
> case, the names might show up on renders in 5-10 years; worst case, the lag
> of standard guidelines on this means that the tagging is wrong or few
> people add this information and renderers never render it.
>
> I understand that tagging standards are based mostly on how many current
> features with  said tag there are and it is therefore slow to change. And
> this process makes some amount of sense for more specialized information.
> But for something as basic as "*how do we tag the place name of an area
> that is not tied to a single feature?*" it baffles me that there is no
> consensus after 16 years. It is clearly a sign that the current process of
> agreeing on tagging standards is not working in this specific case.
>
> /Martin
>
> On Fri, 6 Nov 2020 at 19:34, Anders Torger  wrote:
>
>> Hello everyone, newcomer here!
>>
>> I've been a casual contributing mapper for a couple of years here in
>> Sweden. Only since 2018 :-O, I thought it was longer, and during this
>> time I've made 1700 edits mostly using iD, just started using JOSM for
>> some more complex edits. Anyway, I recently tried to up my game to make
>> really high quality and "complete" maps in the areas I live. I have a
>> lot of local knowledge combined with very high quality government maps
>> (already preloaded into the editor, not the highest resolution version,
>> but enough for most aspects) together with satellite images which today
>> has much better alignment than a few years ago (still government maps
>> are best on that). So good reference is there too, I have all I need to
>> make a good job.
>>
>> My areas are bit more rural, more nature. Villages, hamlets and towns.
>> Nature is prominent and naming nature is important, many old names but
>> still in active use by forestry, outdoor people, hunters and locals.
>> When mapping these, I immediately run into basic issues that I'm
>> surprised that they aren't solved already.
>>
>> I'm not 100% sure if this mailing list is the right venue for discussing
>> these issues. OSM as a community is quite hard to grasp for a newcomer
>> and I have been sent to different places, but now I'm here.
>>
>> Anyway, my observations (mostly using the default openstreetmap-carto
>> style) :
>>
>> ** Tagging bays and straits as areas work great, as the renderer gets
>> and idea how prominent it is and it can make proper text sizing and they
>> can be seen even if zoomed out if the area is large. Lots of our lakes,
>> even quite small ones have sub-naming, and with these features I can
>> make really good mapping of this.
>>
>> ** Tagging and naming areas on ground does not seem to be developed much
>> at all, unfortunately.
>>
>> ** There is natural=peninsula so one can tag and name an area of varying
>> size, but it doesn't seem to render (unless I've made some mistake...)
>>
>> ** I can't make an area to name hills or slopes, which is very common
>> around here (natural=hill would be nice and is more generic than slope).
>> There's peak, but that's only for point for the highest peak with
>> elevation, so it doesn't the purpose here.
>>
>> ** Valleys can only be tagged as ways, but here it would make much more
>> sense to make an area, as sizes of these valleys vary a lot, and the
>> renderer need to know how large this is (not just how long) to make sane
>> renders.
>>
>> ** Due to limitations in area-based name tagging the map looks empty
>> just when zoomed out a little, as names disappear almost directly, so
>> despit

Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 23:39 by and...@torger.se:

>
> One example is making a multipolygon instead of the semantically superior 
> group, as multipolygon actually renders.
>
>
Why multipolygon is supposed to be semantically inferior?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Mateusz Konieczny via Tagging



Nov 6, 2020, 23:10 by dieterdre...@gmail.com:

> Am Fr., 6. Nov. 2020 um 21:04 Uhr schrieb Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> >:
>
>>> ** Support for group naming is limited. It's here very common that several 
>>> smaller islands are named as a group, smaller ponds are named as a group 
>>> etc, without having individual names. There are tags for that 
>>> (group/cluster), but not rendered. 
>>>
>> Mostly because multipolygons are strictly superior.
>>
>
>
> for groups, the group relation is clearly superior. First of all, it implies 
> group semantics and is defined. For a multipolygon, it may not be clear what 
> it is about, unless you invent tags for "a group of lakes", a group of ponds, 
> a group of trees, a group of island. 
>
The same if true for group. There is no semantic difference in creating 
group/cluster/site relation
and tagging with name and creating multipolygon and tagging it with name.

If you want to distinguish "group of islands" from "group of lakes" in both 
cases you need
additional tag or special processing.

> But still, it only works for areas, you cannot use multipolygons for groups 
> of nodes or groups of lines, or mixes of these.
>

Yeah, multipolygons are superior for for cases like mentioned - set of areas.

If you want group of nodes/ways then sadly it stops being a great solution.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Mateusz Konieczny via Tagging
> some of these algorithms could run on GPU clusters these days

No matter where code actually runs you need to have and handle this servers.

For reference basic requirements for a render node include:
80 GB RAM (at least; better 128 GB);
6 or more CPU cores (12+ with HyperThreading, CPU year 2011 or newer eg: Xeon 
X5675);
Storage: 1 TB SSD for database, 1.5 TB HDD (better SSD) for storing tiles;
Fast network connection with high usage or unlimited traffic (at least 30 
TB/month);
( from https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN - requirements
for donated render server)

And yes, with higher budget (for example, with more donated servers) it would 
be a smaller problem.

> the quality of OSM's cartography is held back due to limited server 
> infrastructure.

Note that anyone may develop software for making maps with high quality labels.
It could be running locally/on small areas/very long etc.

I am not involved in this area, but I am not aware about anything either giving 
good results
or reaching some fundamental problems with OSM data format. 
Even dealing with conflicting labels for points, automatic smart dealing with 
long labels and 
multipolygon labelling is as far as I know completely unsolved.

Nov 6, 2020, 23:19 by and...@torger.se:

>
> Sorry for replying to myself, but I forgot to mention one important aspect 
> that I myself hadn't realized until recently: it's seems to be a whole lot 
> about processing power too.
>
>
> Name tag scaling and placement strategies are expensive algorithms compared 
> to what we the default style does now, and I see repeatedly when various 
> improvements to openstreetmap-carto is discussed that "the idea is good and 
> would improve the style, but is unfortunately too computationally expensive 
> so it's not feasible". I suspect that least some of the naming falls into 
> that category, especially when doing smart things when zooming out to give 
> good overview maps.
>
>
> I have not understood why there are these CPU limits, if it's "just" due to 
> under-financed server infrastructure, or if it is a problem that can't be 
> solved regardless of server infrastructure. As a layman one would think that 
> some of these algorithms could run on GPU clusters these days, but I have no 
> idea... it feels a bit problematic though if the quality of OSM's cartography 
> is held back due to limited server infrastructure.
>
>
> /Anders
>
>
> On 2020-11-06 22:51, Anders Torger wrote:
>
>
>>
>> I'd love to help out if the workload and chance of success was reasonable, 
>> but I'm a bit wary about the tagging proposal process. Most of my mapping 
>> contributions is simple things like correcting and adding roads so all the 
>> various online route planners (and indeed bike computers) that use OSM in 
>> one way or another can work in the areas I spend time. For that the map does 
>> not need to be complete at all, I just need a graph of roads, and I use the 
>> regular government-provided maps to actually scout the area.
>>
>>
>> Recently I got more interested in trying to make actual complete and good 
>> cartography, make maps that accurately describes the area (to a certain 
>> detail level) and doesn't require "a real map" on the side for scouting, in 
>> other words make OSM to be a real map in the areas I live. It would also be 
>> nice if one could make hiking maps for the mountains. This is an extremely 
>> ambitious goal, in Scandinavia, and probably many more countries, we are 
>> used at having really great cartography from a special cartography institute 
>> which is a part of the government. Previously the maps were expensive to get 
>> and you could only get it on paper. Today the main aspects exists for free 
>> in digital form (which is a good thing, it's made with tax payers' money 
>> after all). Here, this is the gold standard for a general-purpose map.
>>
>>
>> However, when I see there are some key features missing in OSM to be able to 
>> reach that level, and each of those little features may take years of 
>> processing from proposal to actual implementation in a renderer (and even if 
>> a proposal goes through, I suppose it's not guaranteed that it may be 
>> implemented), then it feels like it's just too much for me, as I'm involved 
>> in many other volunteer projects too. Mapping is not even my main project.
>>
>>
>> To make this happen it seems like I will end up with having to implement my 
>> own style and have my own tile server and using my own tags... it's just not 
>> feasible. What I have done so far in my own mapping applications which works 
>> sort of fine is to use ready-made government maps in a custom layer for the 
>> more zoomed out map (and indeed have an own tile server for that), and then 
>> switch to OSM for the most zoomed in levels. The limitations in name 
>> handling and missing names for large areas is less noticed when fully zoomed 
>> in. But it would be really cool if one could use OSM for the whole 
>

Re: [Tagging] Basic cartography features missing, why?

2020-11-06 Thread Tomas Straupis
2020-11-07, št, 00:41 Anders Torger rašė:
> However, how important is it that update of the map is immediate for every 
> database update? <...>

  OSM-Carto is a style whose purpose is to visualise OSM data to
MAPPERS, do it quickly (fast feedback is essential). OSM-Carto also
has a requirement to be easily deployable by almost anybody on any
hardware. This means that pre-processing of data is impossible as per
requirements (not a design decision). And without pre-processing it is
impossible to have a cartographically sound map. So even while the
OSM-Carto team is doing a terrific job and they do have people with
good cartographic knowledge (like Christopher), but OSM-Carto does not
have such a purpose - cartography.

  We're playing around with a small project striving to comply with
cartographic rules - topo.openmap.lt - some data is updated daily,
generalisation is done weekly. But you already get generalised roads,
buildings, smart lines for waterbody labels as well as text size and
letter spacing. This should get cartographic simplification for
waterways this coming spring (not DP or VW, but Wang-Müller). So this
can be done, but OSM-Carto is not the place to do it.

  Therefore if you want to have a cartographically sound map - you
will need a separate project - separate rendering and stuff. You're
totally right - for general (not mapper) use, minutely update is less
important than cartographically correct representation. And also not
everything has to be generalised, some parts could be updated very
fast, some could be updated weekly or even monthly. Segmentation of
data could also get more attention (re-calculating only the parts
which need re-creation). Such tasks could even push forward topics
which are currently the target of generalisation and multiple
representation group of International cartographic association - I
really think OpenStreetMap has people and capabilities to have a say
there.

-- 
Tomas

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