[Tagging] Basic cartography features missing, why?

[Mateusz Konieczny]

Nov 6, 2020, 19:31 by anders at 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 many
people are completely unfamiliar with such pictures.

I just want to say that I think that amenity=parking can be used if area is commonly used
for parking and parking is legal there, even if it was not developed as some paved parking lot.

> Maybe it's technically difficult to implement.
>
That is the biggest problem. Automatic smart label placement is awfully hard.

See https://github.com/gravitystorm/openstreetmap-carto/search?q=label&type=issues

See for example https://github.com/gravitystorm/openstreetmap-carto/issues/4241 
("Norge label rendered on svalbard instead of mainland") for what kind of issues are 
happening for seemingly easy cases.

For cases that are actually very complex...

>  Maybe it's technically difficult to make any new things at all as the database has grown. Maybe it's hard to get acceptance for new features as the community has grown large and diverse.
>
That is sometimes a problem, but not main blocker in this case.

>  Maybe OSM is not intended for mapping natural features.
>
Not a problem, mapping natural features IS in scope.

>  Maybe the ability to show anything useful other than maximally zoomed in isn't a priority.
>
It is kind of reduced in importance for some data consumers as zooming in is
possible, so showing everything in a given view is less important than for paper maps.

>  Maybe rural areas isn't important to OSM.
>
"important to OSM" is tricky, as OSM in without some top-down leadership.

But rural areas tend are in scope of OSM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201106/3cbb50e3/attachment-0001.htm>