subject:"\[Tagging\] Basic cartography features missing, why\?"

Thanks for your long and thoughtful reply. I'll try to not make it even 
longer :-).


While I have only contributed since 2018, I've followed the project for 
much longer (that's why I though I had contributed for longer until I 
checked my log), so I've seen how the maps have looked and developed. 
But mostly really only in Sweden, so I do indeed have a local 
perspective.


I believe the processes available are limited in terms of fixing 
structural problems. It works well to add things into an existing 
structure (if you're not in a hurry). A "GOOD idea" is thus one that 
takes little effort and has little controversy, like adding a minor new 
tag preferably one which really don't need to render on OSM-Carto. If 
you need to do something that requires structural change or adjustment 
it seems you're in for a rough ride. Sure that's natural of course, but 
it becomes a bit like trying to run a multi-national company with no 
leadership, just consensus-voting with people "on the floor" inside 
their own local bubble (like myself).


The principle if you see a problem, then you fix it on your own: I know 
all about it, I've worked in many open-source projects small and large 
and released several on my own, some still in active use 20 years later. 
However when something gets truly big, total decentralization can become 
problematic, and at some point many can't thrive only on voluntary 
contributions, some parts need professionalization and corporate 
sponsorship etc. Large successful open-source projects have evolved 
their organizations to adapt to new situations.


"Fix it on your own" is how imports seems to have been managed. With 
varying success. It has worked well in countries were the community is 
strong and technically skilled, but in countries with weaker local 
community, like Sweden, it hasn't worked. I think the problem is that as 
OSM has grown so has the technical expertise required to "fix it on your 
own" so the threshold has just become too large for casual contributors. 
You basically need to be a professional or have this as your only big 
hobby plus have developed engineering skills to be able to make a good 
job, and judging from the results exactly zero such people exists in 
Sweden. Therefore I think OSM should strive to have a professionalized 
import task force where imports are centralized, and merging with 
existing data is made by the crowd of casual mappers according to clear 
guidelines.


Listening to Alan Mustard's talk "Winds of Change in OpenStreetMap" 
https://2020.stateofthemap.org/sessions/RRVNAM/ I get some hope though 
as it seems like these issues are being taken seriously. If you haven't 
listened to that already I recommend it.


Anyway, what is my evidence of all this you ask? We'll let's say I'm 
gathering it ;-). The first thing that got me wondering without knowing 
much at all about OSM's inner workings is the observations I've made as 
a cartography-interested private individual (I'm an outdoor guy), and as 
such regularly visiting www.openstreetmap.org to see if the map had 
become useful yet. Obvious cartographic shortcomings existed 10 years 
ago, and the same ones are still present. I thought when the government 
public data was released here in Sweden back in 2015 at last that there 
would be a boost of the baseline data at least. Nothing happened.


And I've read other criticisms of the project, emacsen's blog post is 
perhaps the most significant.


If OSM intends to be global, it must be able to adapt to local 
conditions which do vary over the globe. Sure you can say that ok, OSM 
has a hard time in Sweden and some other minor European countries, but 
that's no problem, because it works great in the US! I hope OSM to be a 
global project though.


Sure one can argue if cartographic generalization actually needs to work 
better than it does today. Let's say I'm surprised if it's generally not 
considered to be a problem. I know I've read about the empty rural map 
problem quite long time ago and more than once, so I'm not the only 
person that has seen this. The problem with naming groups and land areas 
I actually did not know about until now, simply because noone has named 
much at all in nature in Sweden so far. But after I've mentioned it I 
see others having the same problem, but as it's often not critical, 
especially in dense areas, it's easy to just drop it, there are often 
more pressing features to cover.


But now I get told that getting support for this type of feature is 
typically a 4 - 8 year long process. Hmm... it's feels like opening a 
graphic design software, and get to know that I can't draw circles for 
another 4 - 8 years. Sure I can do all the boxes instead, and put a 
point where it should be a circle, and hope someone fix it later. Maybe 
I'll do exactly that. But I don't think it should be surprising that 
cartography interested casual contributors like myself are struck with 
frustration when they see these

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

From a tool point of view (JOSM etc), multiple databases could be made 
to be experienced exactly the same as different layers, so I guess it 
doesn't matter that much.


With layers you are supposed to be able to turn them on and off at will 
in your editor and choose which you see in an easy way, so such problems 
could be easily spotted and fixed anyway. You could also have automatic 
checkers for layer overlaps. Those issues could be managed, and I think 
the advantages of a layered design clearly outweigh the disadvantages, 
especially when we get more and more data density and more and more 
different types of data.


I don't really care that much exactly how it's implemented, but a 
potential risk I see with having separate databases, perhaps maintained 
by some other entity, rather than readily integrated in the main 
database is that it will get stuck as a niche feature not used by 
OSM-Carto or any of the big providers.


On 2020-11-08 13:41, Tomas Straupis wrote:

2020-11-08, sk, 12:31 Anders Torger rašė:

To me it seems like an odd "political" design decision to have a
separate database though. Why just not arrange the database in layers,
and this could be a separate layer? From a technical perspective I
suppose it wouldn't have to be layers as such, one layer could in
actuality be a tag filter.


  It must be separate enough to:
  * not allow reusing objects from "main" database
  * to have different description on what is allowed in it (for
example allowing objects borders of which cannot be precisely defined
etc.)

  In general it is an advantage that the main database does not have
layers. In "standard GIS" layers separate data thus we can get bus
stops in the lake or on the building, road going into the lake etc. In
OSM it is much easier to spot such problems (and fix them) because it
is only one layer.


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

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

2020-11-08 Thread Ture Pålsson via Tagging



> 6 nov. 2020 kl. 19:31 skrev Anders Torger :
> 
> Hello everyone, newcomer here!
> 

Only marginally related to the discussion, but: For Sweden, you may want to 
look at the rendering at http://lab3.turepalsson.se/map/ 
 (the generated PDF:s, not the tiles; those 
are horrible at smaller scales. :-) )

If there’s any data that isn’t rendered but should be. I can probably add that 
quite easily.

(The data used may be a few weeks old, since I need to trigged rendering DB 
updates manually.)

 — T


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

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

2020-11-08 Thread stevea

Warning:  lengthy reply to an already-lengthy thread.

On Nov 8, 2020, at 3:26 AM, Anders Torger  wrote:
> Regarding a board that makes strategic decisions.
> 
> The current concensus model with huge community has lead to that it's very 
> easy to block an idea, and very hard to get it accepted and realized.

Anders, here, we disagree.  If you have a GOOD idea in OSM, you may implement 
it rather directly.  If it is truly "good," the community will adopt it with 
enthusiasm.  Sometimes there are misunderstandings by some (even at the 
top-most levels of the project, like the DWG), though for the most part, these 
are remedied with time.  Sometimes people choose not to "be bold" (rather 
simply implementing something like a tag "in the wild") but rather go the route 
of proposals, voting and slower, more widely and immediately acceptable 
community acceptance, providing the vote goes to Approved.

I have had experience with all of these:  good ideas which were widely not 
well-understood (at first), even by DWG members, yet they are now well 
established and well run sub-projects within OSM, as well as poor ideas which 
didn't go anywhere at all because few or no community members support them.  
Presenting good ideas well takes effort, yes, but it isn't correct to 
characterize this as "very hard."  Maybe for someone who has little or no 
experience in presenting an idea, communicating it well and having others 
accept this it might be "hard," (not "very hard"), but this is a life skill, 
not one limited to a worldwide, open project.  It isn't (usually) the fault of 
a project (or institution) when good ideas well-presented to it get "blocked," 
much more often it is the idea or its presentation.  If OSM truly has a "block" 
on accepting good ideas well-presented to it, we must fix this.  But I don't 
believe this is true, nor do I believe this is widespread in OSM.  If you have 
evidence otherwise, please present it.

> A good idea is often blocked just because the first suggested solution may 
> not be the best. It's rare to see, "it's a good idea, but maybe we could 
> implement it like this instead?", but it's rather "your idea for 
> implementation is bad because xyz, end of discussion". Many of those that has 
> ideas are casual laymen, like myself, and we don't have the ability to run 
> these processes, and may not have the knowledge to come up with the best way 
> to implement it. It's very hard to get a grasp of what's needed and what 
> people actually think in general, it's more about shouting the loudest. With 
> a larger database in more complex use cases it's also become much more 
> technically difficult to make changes, so the people which actually can on 
> their own design a technical solution is extremely rare.

Again, I disagree it is about "shouting the loudest."  While it may seem that 
the consensus process is more like dissonant cacophony, we largely remain civil 
while sifting out the wheat from the chaff (good ideas, like cream, DO tend to 
"rise to the top") and any "shouting" or disagreement is mostly a bit of heat 
on the way to achieving light.  It can be messy, it isn't perfect, but building 
consensus isn't what is wrong with OSM, it is an important part of what is 
right.  Speaking for myself, I don't want some "star chamber" (secretive cabal 
on high) to be developing the future of OSM.  I want me, my fellow OSM 
volunteers, you and others to do so:  this is called "organic grass-roots 
growth."  As individuals, we all have strengths that allow us to contribute, 
these sorts of things tend to work themselves out with the usual "we need some 
help here, does anybody have the required expertise" and "I see a problem I 
might be able to solve like this, as I DO have some expertise in the specific 
realm..." so, you fix it, maybe with others, maybe by yourself.  We don't 
really have "cabals on high" in this project, although we do have local chapter 
boards we (as members) elect to do some of the necessary housekeeping (legal, 
data, others) that a project this large requires.  I'm actually in the process 
of "designing a technical solution" with two or three (maybe four) other 
long-term OSM volunteers:  we collaborate on the syntax of improving park 
boundaries and protected areas (a confusing and doesn't-render-consistently 
problem area in OSM).  It might take ANOTHER year to get this right, that's OK, 
we have the patience to do so.  This isn't rare, it is OSM in action.

It might take time, a lot of reading (of wiki, of technical documentation, 
sometimes repositories like GitHub...) and consultation with wiser, more 
experienced people when you run into a block, but those kinds of activities are 
true of any (larger) organization as one might strive to make it better, grow 
or solve problems within it.  Again, you are asking good questions, but it 
seems you lack some experience in how OSM works, or suffer from what I'm sad to 
say I think a lot of volunteers in OSM

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

2020-11-08 Thread Tomas Straupis

2020-11-08, sk, 09:46 Mateusz Konieczny via Tagging rašė:
> (and it is from person who put a lot of effort into tagging improvements, 
> wikifiddling,
> deprecating some unwanted values, deduplication and validator-related work 
> and has
> some experience from data consumer side)

  That is a lie, as you're supporter of harmful duplication of water schema :-D

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

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

2020-11-08 Thread Tomas Straupis

2020-11-08, sk, 12:31 Anders Torger rašė:
> To me it seems like an odd "political" design decision to have a
> separate database though. Why just not arrange the database in layers,
> and this could be a separate layer? From a technical perspective I
> suppose it wouldn't have to be layers as such, one layer could in
> actuality be a tag filter.

  It must be separate enough to:
  * not allow reusing objects from "main" database
  * to have different description on what is allowed in it (for
example allowing objects borders of which cannot be precisely defined
etc.)

  In general it is an advantage that the main database does not have
layers. In "standard GIS" layers separate data thus we can get bus
stops in the lake or on the building, road going into the lake etc. In
OSM it is much easier to spot such problems (and fix them) because it
is only one layer.

-- 
Tomas

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

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

2020-11-08 Thread Yves via Tagging

Maybe I'm wrong, but can I use OSM tiles to help tracing a 'Blue Valley' 
polygon, simplify or copy a multipolygon 'Martin' s wood' or whatever and 
declare it cc0? 
Yves 


Le 8 novembre 2020 11:08:57 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 8. Nov 2020, at 10:08, Yves  wrote:
>> 
>> * CC0 doesn't allow to derive data from OSM
>
>
>it does. The whole point (for me) to start this was to provide data that can 
>be combined with OpenStreetMap. What would be your suggestion for a licence? I 
>would be willing to double licence it with WTFPL, would that help?
>
>
>Cheers Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Regarding a board that makes strategic decisions. 


The current concensus model with huge community has lead to that it's
very easy to block an idea, and very hard to get it accepted and
realized. A good idea is often blocked just because the first suggested
solution may not be the best. It's rare to see, "it's a good idea, but
maybe we could implement it like this instead?", but it's rather "your
idea for implementation is bad because xyz, end of discussion". Many of
those that has ideas are casual laymen, like myself, and we don't have
the ability to run these processes, and may not have the knowledge to
come up with the best way to implement it. It's very hard to get a grasp
of what's needed and what people actually think in general, it's more
about shouting the loudest. With a larger database in more complex use
cases it's also become much more technically difficult to make changes,
so the people which actually can on their own design a technical
solution is extremely rare. 

As a result the pace of development is glacial. 


16 years of age and still basic cartography features missing, that's why
I started this thread in the first place. You have a core inside group
that thinks OSM is great in most ways and really nothing needs to be
changed, and even those things that needs change are just too hard to
change so there's little idea to even discuss it. I've been criticized
for putting out a narrative that the competition is may be moving past
us, but I do think that can happen in various parts of the world. The
two main "threats" are government maps made public / low cost and Google
Maps. 


In many cases the public government maps can be used to our advantage as
they in many cases can be used as basis for an import. But in certain
countries, like Sweden where I live, this haven't worked well despite
the data has been there for 5 years and almost 100% of the Swedish OSM
map would benefit from import (of high quality!). This is a huge problem
for OSM here locally. I dare to say that the general view of Swedish
people regarding maps is that OSM is already obsolete. I know many that
played around with it 7-8 years ago when maps were expensive and hard to
get, but now they use services that have maps based on government data,
and google maps is coming strong (although it's still pretty bad, but it
is showing progress). Now few even know that OSM is actually used via
providers in say facebook, and various global fitness applications. In
other countries the situation can be totally different of course. 


A board would not have as goal to run over people. It would identify
risks, identify things that needs professionalization, manage commercial
collaborations, and just make things happen. 


Or maybe there is some other way forward. But I think something needs to
change if we want to 1) be able to attract new mappers, 2) stay relevant
long term. 


I strongly believe that openstreetmap.org needs to present a set of
great end user maps for the most common use cases. It might hurt
business of mapbox and others short term, but will help them long-term.
There will always be need for additional styles and custom maps even if
the official OSM maps are made great for typical applications. 


We already have the start of that on www.openstreetmap.org [3] and
recently another layer was added, but well, in my humble opinion the
renderings are not great due to lacking cartography features. And the
website is actually more of an entry point for mappers rather than end
users, which is really odd. I don't even know where to send newcomers
when I want to show them what OSM can do. I think www.openstreetmap.org
[3] should be an end user site, and say something like
edit.openstreetmap.org could be the site as it is now. I think we need
to think about how OSM is experienced from the outside, unless we just
want it to become a niche handicraft object for ourselves. And by the
way the website looks exactly the same it did like 10 years ago. That's
good for an edit website for insiders. It's not good for being the face
of OSM, and contributes to the view that development is glacial even if
a lot happens under the surface. Sure people like us usually don't like
website fashion, but we can't just ignore how OSM is experienced from
the outside. Oh well, we can, but I don't think it's a good idea
long-term. 


Garmin has a vector rendering of openstreetmap in their connect fitness
web app, they also have Google and HERE as alternative layers. The
vector openstreetmap layer is no way showing near what actually is in
the current database, and there's various artifacts. A huge lake where I
live is missing alltogether (probably because the polygon is made in
some way that vector engine can't understand). I think this is just one
example what happens with the fragmented landscape of OSM map providers
and that our own maps are not able to fulfill the needs of typical
applications. Garmin as being hugely popular in Sweden among fitness

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

2020-11-08 Thread Allroads

Toponym key
Used at a import.
https://wiki.openstreetmap.org/wiki/3dShapes/Landuse_import
Translation:
Toponyms are used to still be able to apply a name = * to a large area, even if 
this has been divided into tens to hundreds of small pieces due to the import.
The existing AND polygons with a name = * will remain, but will be tagged to 
toponym.
landuse = forest of natural = wood with a name convert to toponym = forest + 
area = yes.


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

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


Beautiful name label rendering!

Regarding separate database, I think it's a good idea if that is the 
only way forward. Something needs to happen. Being able to fulfill basic 
cartography needs are not "new" ideas, I really believe that it should 
be a priority for a database used for generating maps so it's sad to see 
that it's being blocked. This is also a space which seems to be were we 
can have an edge when more and more maps are moving into vector. I see 
that many providers actually go backwards in cartography when moving to 
vector (due to worse name label management), but we could instead go 
forward, and topo.openmap.lt is an inspiring example.


To me it seems like an odd "political" design decision to have a 
separate database though. Why just not arrange the database in layers, 
and this could be a separate layer? From a technical perspective I 
suppose it wouldn't have to be layers as such, one layer could in 
actuality be a tag filter.


That we get stuck on arguments about cluttering the database with 
"unmaintainable polygons" I see simply as a database management problem.


What if we in the future want to have specialty maps like say bedrock 
maps? Of course putting those polygons all over the others in the same 
database will be a mess. Already the data is slow to manage and edit for 
my lowly machine in dense areas as one get all layers at once even if 
one only wants to work on say coastlines. Once imported to JOSM I can 
work with filters, so it's manageable, but I think it would be *much* 
better if layers got to be a more defined feature.


I also see that layers could be an advantage for import processes, you 
could create a separate layer for making a huge import which is not used 
in rendering, but used by casual mappers during long-term manual 
merging. (As a side note I also think that OSM needs a professionalized 
import task force working for a year or so to boost countries with good 
local public data and bad OSM data, instead of individuals here and 
there make their best attempts of making an import which can be really 
technically challenging, which we see the effects in our Swedish map 
now).


On 2020-11-08 06:51, Tomas Straupis wrote:

2020-11-08, sk, 00:00 Anders Torger rašė:

Maybe this is self-evident to anyone that knows more about this than I
do, but I have to ask, are you saying that when we have to implement
generalization to be able to serve vector tiles, it's also natural to
include generalization of names? Meaning that we could see more names
than we do now when we zoom out, so perhaps rural areas don't get the
empty-map-syndrome? That would be awesome.


  Names do not take too much space in vector tile. I was talking about
larger objects like landcover, water, buildings.


In addition I still want some method to name features in the landscape
though, that supports automatic generalization. I thought named areas
was an elegant way to do this, but it seems some have very strong
opinions against it.


  If we're talking about fuzzy features (which do not have specific
boundaries) like mountain ranges, bays, straits etc. the problem is
that just a point is not enough, text must have direction, sometimes
even curvature to follow the geometry of the object ant thus "connect"
the label with the object in our consciousness. Additionally, for some
objects, say bays, we need totally different set of labels for
different zooms and that can only be calculated if we have a polygon
(check water labels and how they change
https://topo.openmap.lt/#t/13/54.33547/24.36494/0/0/ starting with
zoom 16 there is actually a lot of labels placed in different places
of the waterbody). But placing polygons for fuzzy objects have
problems:
  * borders are not verifiable on the ground (as there is actually no
border - object is "fuzzy")
  * imprecisely drawn boundaries of such objects look bad in the
editor, intersect with other objects and this kind of pushes mappers
to simply use boundaries of  existing features (like coastlines) which
makes those object waay too precise for fuzzy objects.
  My personal opinion is that such objects could be moved to a
separate database specific to fuzzy objects. That database should not
have ANY connection to the main database so that mappers would not be
able to reuse geometries of the main database. Thus license would be
the same, toolchain would be the same, data could later be used
alongside the data from the "main" database. Everyone should be happy,
both arguments (Christophs and Frederiks) against such objects would
be satisfied?


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

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

2020-11-08 Thread Martin Koppenhoefer

sent from a phone

> On 8. Nov 2020, at 10:08, Yves  wrote:
> 
> * CC0 doesn't allow to derive data from OSM

it does. The whole point (for me) to start this was to provide data that can be 
combined with OpenStreetMap. What would be your suggestion for a licence? I 
would be willing to double licence it with WTFPL, would that help?

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

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

2020-11-08 Thread Yves via Tagging

Good initiative Martin, at first sight I'll make two comments :
* CC0 doesn't allow to derive data from OSM
* as geometries are fuzzy in nature, there should be a way to accept several 
geometries for a same entity, be it only to avoid long discussions on boundaries
Yves 

Le 8 novembre 2020 09:47:04 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>
>sent from a phone
>
>> On 8. Nov 2020, at 09:24, Mateusz Konieczny via Tagging 
>>  wrote:
>> 
>> I really like an idea of separate database/layer for such fuzzy objects.
>
>
>I have started a project to collect such fuzzy objects. Data is stored in a 
>git repo in Geojson representation. Pull requests welcome.
>https://github.com/dieterdreist/OpenGeographyRegions
>
>Cheers Martin 
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

2020-11-08 Thread Martin Koppenhoefer

sent from a phone

> On 8. Nov 2020, at 09:24, Mateusz Konieczny via Tagging 
>  wrote:
> 
> I really like an idea of separate database/layer for such fuzzy objects.

I have started a project to collect such fuzzy objects. Data is stored in a git 
repo in Geojson representation. Pull requests welcome.
https://github.com/dieterdreist/OpenGeographyRegions

Cheers Martin 

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

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

2020-11-08 Thread Mateusz Konieczny via Tagging

I really like an idea of separate database/layer for such fuzzy objects.

Especially as there are multiple competing ideas for when specific
object ends and even how many continents/oceans we have.

Nov 8, 2020, 06:51 by tomasstrau...@gmail.com:

> If we're talking about fuzzy features (which do not have specific
> boundaries) like mountain ranges, bays, straits etc. the problem is
> that just a point is not enough, text must have direction, sometimes
> even curvature to follow the geometry of the object ant thus "connect"
> the label with the object in our consciousness. Additionally, for some
> objects, say bays, we need totally different set of labels for
> different zooms and that can only be calculated if we have a polygon
> (check water labels and how they change
> https://topo.openmap.lt/#t/13/54.33547/24.36494/0/0/ starting with
> zoom 16 there is actually a lot of labels placed in different places
> of the waterbody). But placing polygons for fuzzy objects have
> problems:
>  * borders are not verifiable on the ground (as there is actually no
> border - object is "fuzzy")
>  * imprecisely drawn boundaries of such objects look bad in the
> editor, intersect with other objects and this kind of pushes mappers
> to simply use boundaries of  existing features (like coastlines) which
> makes those object waay too precise for fuzzy objects.
>  My personal opinion is that such objects could be moved to a
> separate database specific to fuzzy objects. That database should not
> have ANY connection to the main database so that mappers would not be
> able to reuse geometries of the main database. Thus license would be
> the same, toolchain would be the same, data could later be used
> alongside the data from the "main" database. Everyone should be happy,
> both arguments (Christophs and Frederiks) against such objects would
> be satisfied?
>
> -- 
> Tomas
>
> ___
> 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?




Nov 8, 2020, 05:31 by mach...@gmail.com:

> I absolutely agree with Seth, OSM should switch to vector tiles ASAP. 
>
Note that OSM would not switch to vector tiles. At most one more rendering 
would switch
to vector tiles.

For OSM Carto see 
https://github.com/gravitystorm/openstreetmap-carto/issues/3201
(not sure what is the state and what is the current blocker)

(sorry if that is overly pedantic)

> And there should be several specialized layers: general car navigation map, 
> sport map for hiking/cycling/skiing, transportation. All of that would be 
> possible with vector tiles which are less computationally demanding to create.
>
We already have multiple map styles.

> Their code is all on github so no need to reinvent the wheel and I think this 
> could be easily modified for OSM purposes.
> https://github.com/FreemapSlovakia
>
Is there somewhere description/summary of their software stack?

> If there is nobody who can or is willing to do it then let's hire someone who 
> can. 
>
> Or let a company like Mapbox do it.
>
If someone, anyone is willing to sponsor hosting they can propose to add
their tiles to OSM main site (see 
https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers
)

Though as business of Mapbox is to offer paid hosting of OSM data it is dubious 
that they
would put special effort into competing with themself. Even free tier of their 
products
requires giving credit card details.

>  I would be willing to do regular monthly donations for someone's salary if 
> that makes OSM better and more attractive.
>
I am not sure how one may donate for specific target of vector tiles
(it is also not mentioned at https://wiki.openstreetmap.org/wiki/Donations ). 

donati...@openstreetmap.org is appearing on the page, maybe asking there is
there such possibility would be useful

> I also fully agree with Anders. OSM needs change. There should be some sort 
> of committee with a clear vision that would enforce a unified style of 
> mapping.
>
While central power may be useful and offer some benefits, it is really poor 
place for it.

Either some agreement can be reached and such committee is not needed or they
would make decisions where large part of community disagrees with it.

Except cases where this is absolutely needed, such entity would do more damage
than benefit.

> It is absolutely ridiculous that we have features that are mapped in 2 or 
> more different ways simultaneously e.g. riverbanks or sidewalks... Who is 
> supposed to use and rely on such data?
>
Duplicate tags are mildly irritating while processing, but it is not a serious 
or main problem for
data consumers. 

(and it is from person who put a lot of effort into tagging improvements, 
wikifiddling, 
deprecating some unwanted values, deduplication and validator-related work and 
has
some experience from data consumer side)

>
> Martin
>  
>  
>
>> Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan
>>
>> I actually just found that article about OSM’s problems.
>> One of the major topics mentioned, the fact that OSM acts as a database and
>> not a map, and that this acts as a hinderance to the expansion and
>> development of the project, is very true.
>> As a result, I’ve came to think that implementing Vector tiles should be
>> OSM’s #1 development priority right now. If people who find OSM realize
>> that there’s a lot more data than just the raster images displayed by the
>> standard tile layer, than they will be more likely to contribute and grow
>> the OSM community.
>> We’re all here complaining about computational needs required by rendering
>> servers, but there are some great vector tile implementations that require
>> way less computational needs.
>> Moral of the story: We need Vector tiles.
>> El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger <>> and...@torger.se>> >
>> escribió:
>> > This is great information, I didn't know about your project, very very
>> > interesting. I have recently come to understand the OSM-Carto technical
>> > challenges recently. I haven't given it much of a thought as a casual
>> > mapper for the past two years, just been a bit disappointed with how it
>> > looks.
>> >
>> > I am a programmer in profession though so when taking a deeper look and
>> > though about it I see these challenges.
>> >
>> > However, and this is a big however, I think that the face of
>> > openstreetmap really need to be a cartographic sound map. It's not right
>> > that a style seemingly designed mainly for speedy diagnosis should be
>> > the face of OSM. How many of our mappers are so technical that they
>> > understand this? And howcome did I not even know about this cartographic
>> > project of yours? If there are great styles out there but noone knows
>> > about them that's a problem.
>> >
>> > And even if we let the not-so-good-cartography be the first map we see
>> > on >> openstreetmap.org >>  (which makes no 
>> > sense), some of the other

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

2020-11-08, sk, 00:00 Anders Torger rašė:
> Maybe this is self-evident to anyone that knows more about this than I
> do, but I have to ask, are you saying that when we have to implement
> generalization to be able to serve vector tiles, it's also natural to
> include generalization of names? Meaning that we could see more names
> than we do now when we zoom out, so perhaps rural areas don't get the
> empty-map-syndrome? That would be awesome.

  Names do not take too much space in vector tile. I was talking about
larger objects like landcover, water, buildings.

> In addition I still want some method to name features in the landscape
> though, that supports automatic generalization. I thought named areas
> was an elegant way to do this, but it seems some have very strong
> opinions against it.

  If we're talking about fuzzy features (which do not have specific
boundaries) like mountain ranges, bays, straits etc. the problem is
that just a point is not enough, text must have direction, sometimes
even curvature to follow the geometry of the object ant thus "connect"
the label with the object in our consciousness. Additionally, for some
objects, say bays, we need totally different set of labels for
different zooms and that can only be calculated if we have a polygon
(check water labels and how they change
https://topo.openmap.lt/#t/13/54.33547/24.36494/0/0/ starting with
zoom 16 there is actually a lot of labels placed in different places
of the waterbody). But placing polygons for fuzzy objects have
problems:
  * borders are not verifiable on the ground (as there is actually no
border - object is "fuzzy")
  * imprecisely drawn boundaries of such objects look bad in the
editor, intersect with other objects and this kind of pushes mappers
to simply use boundaries of  existing features (like coastlines) which
makes those object waay too precise for fuzzy objects.
  My personal opinion is that such objects could be moved to a
separate database specific to fuzzy objects. That database should not
have ANY connection to the main database so that mappers would not be
able to reuse geometries of the main database. Thus license would be
the same, toolchain would be the same, data could later be used
alongside the data from the "main" database. Everyone should be happy,
both arguments (Christophs and Frederiks) against such objects would
be satisfied?

-- 
Tomas

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

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

2020-11-07 Thread Martin Machyna

I absolutely agree with Seth, OSM should switch to vector tiles ASAP. And
there should be several specialized layers: general car navigation map,
sport map for hiking/cycling/skiing, transportation. All of that would be
possible with vector tiles which are less computationally demanding to
create.

As an example, a small community in Slovakia used to render low zoom tiles
on their server and high zoom tiles on volunteers' home computers and the
update time was quite long. After they switched to vector tiles, all is
rendered on the server only and instead of 1 country now they render 16+
countries with fast refresh and on-demand rendering.

And I personally think the result looks pretty good:
https://www.freemap.sk/?map=14/48.930467/19.094570=X

Their code is all on github so no need to reinvent the wheel and I think
this could be easily modified for OSM purposes.
https://github.com/FreemapSlovakia

If there is nobody who can or is willing to do it then let's hire someone
who can. Or let a company like Mapbox do it. I would be willing to do
regular monthly donations for someone's salary if that makes OSM better and
more attractive.

I also fully agree with Anders. OSM needs change. There should be some sort
of committee with a clear vision that would enforce a unified style of
mapping. It is absolutely ridiculous that we have features that are mapped
in 2 or more different ways simultaneously e.g. riverbanks or sidewalks...
Who is supposed to use and rely on such data?

Martin



> Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan
>
> I actually just found that article about OSM’s problems.
> One of the major topics mentioned, the fact that OSM acts as a database and
> not a map, and that this acts as a hinderance to the expansion and
> development of the project, is very true.
> As a result, I’ve came to think that implementing Vector tiles should be
> OSM’s #1 development priority right now. If people who find OSM realize
> that there’s a lot more data than just the raster images displayed by the
> standard tile layer, than they will be more likely to contribute and grow
> the OSM community.
> We’re all here complaining about computational needs required by rendering
> servers, but there are some great vector tile implementations that require
> way less computational needs.
> Moral of the story: We need Vector tiles.
> El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger 
> escribió:
> > This is great information, I didn't know about your project, very very
> > interesting. I have recently come to understand the OSM-Carto technical
> > challenges recently. I haven't given it much of a thought as a casual
> > mapper for the past two years, just been a bit disappointed with how it
> > looks.
> >
> > I am a programmer in profession though so when taking a deeper look and
> > though about it I see these challenges.
> >
> > However, and this is a big however, I think that the face of
> > openstreetmap really need to be a cartographic sound map. It's not right
> > that a style seemingly designed mainly for speedy diagnosis should be
> > the face of OSM. How many of our mappers are so technical that they
> > understand this? And howcome did I not even know about this cartographic
> > project of yours? If there are great styles out there but noone knows
> > about them that's a problem.
> >
> > And even if we let the not-so-good-cartography be the first map we see
> > on openstreetmap.org (which makes no sense), some of the other layers
> > presented there should be one which focus on good cartography, and all
> > that are there now have many of the same issues as the main style.
> >
> > I assume that many, perhaps most, casual mappers use the web editor. I'm
> > really impressed with the web editor, it's great and is mostly
> > user-friendly, you don't need to be a technical person to map, and that
> > is how I think it should be. One thing with the web editor though is
> > that unless you are technical enough to turn off caching (which
> > essentially means putting the browser in development mode), you won't
> > see the rendered results for a long time, even if reloading the page,
> > you still get cached data. Thus it wouldn't matter if the rendering
> > wasn't updated for a couple of hours or even more, the casual mapper
> > won't see it anyway.
> >
> > I think that direct feedback is desirable of course, but compared to
> > other goals I think it's less important, and one can work with the user
> > interface in the web editor to mitigate this issue. Perhaps just have a
> > way to probe the server so it can deliver some render status. The
> > biggest problem today with the web editor regarding feedback is that to
> > a casual mapper it may not be obvious that the map needs to be rendered
> > at all and that can take time, and together with the web caching and
> > different zoom levels it gets even more confusing. Many of us more
> > experienced mappers know exactly how OSM works and renders, and we go
>

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

I'm don't know that much cartography terms and techniques, I only know 
what I know from using maps. I have noted though that traditional maps 
simplify the geographic shapes depending on scale. Sometimes in 
interesting ways, instead of removing small islands they are sometimes 
drawn bigger instead. It's actually quite elegant as it makes the map 
pack more information. It's probably not the right thing to do for an 
automatic generalization though, as it would be impossible to know which 
islands that has importance enough to be enlarged and kept rather than 
just removed.


Although OSM-Carto doesn't do any generalization of the shapes when 
zooming out I think it works quite fine on a computer screen, so I 
personally don't see it as a problem, but I guess a true cartographer 
will :-). In any case, when going to vector shapes it will obviously be 
necessary from technical reasons.


Maybe this is self-evident to anyone that knows more about this than I 
do, but I have to ask, are you saying that when we have to implement 
generalization to be able to serve vector tiles, it's also natural to 
include generalization of names? Meaning that we could see more names 
than we do now when we zoom out, so perhaps rural areas don't get the 
empty-map-syndrome? That would be awesome.


In addition I still want some method to name features in the landscape 
though, that supports automatic generalization. I thought named areas 
was an elegant way to do this, but it seems some have very strong 
opinions against it. Named points of natural features of different sizes 
would also work (like isolated dwelling < hamlet < village < town) but I 
don't think it is as elegant and provides less information as one 
actually can map out an area even if the borders are fuzzy. But, a point 
with size does the job so I think that is acceptable if one could get 
consensus on that. Points all with the same prominence which is offered 
today for some of the features I need to name does not work though as 
the generalization will then not be representative of the area.


On 2020-11-07 20:44, Tomas Straupis wrote:

One more thing to consider: generalisation is one of the most
important things for cartography, but it is also extremely important
for vector tiles. 2-3 years ago we've played with government data and
it produced huge (up to 4MB) vector tiles (pbf) for middle scales
(zoom 8-12). Browsers (especially mobile ones) were struggling with
that amount of data. Even moderate generalisation reduced the amount
of data to 0,5M. It is something which is currently brushed under the
carpet as using raster will never produce a tile that large. What I'm
saying here is that generalisation (the real one, not DP) will have to
be done anyways as OSM community is starting to see the disadvantages
of legacy raster maps and is getting used to the idea of vector maps
(for the client, not between servers).

2020-11-07, št, 21:23 Anders Torger rašė:
(I had to run it in Chrome, it didn't render properly in my Firefox, 
but

this vector stuff is new tech and Linux Firefox seems to have some
issues with that.)


  Strange. Firefox on linux is my primary browser, it is the way I
always use/test *.openmap.lt...


Okay, change that to "Firefox on *my* Linux computer" :-)... it's not 
the first time it seems like I am having issues with that which no-one 
else has... hmm... maybe I have been toying too much with the GPU 
settings.


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

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

2020-11-07 Thread stevea

On Nov 7, 2020, at 9:14 AM, Anders Torger  wrote:
> Hello Steve,
> thanks for that wonderful and inspiring post! I'll surely think about 
> doing-what-can-be-done-with-the-current-tools-at-hand, and think about that 
> the work can be built upon by others in the future. Most inspiring!

You are welcome!  I'm glad we resonate on at least a couple of levels (likely 
more).  I love it when that happens in OSM.

> And I'll also clarify, I don't expect some Swiss cartographic artwork to come 
> out of the renderer. But I do think that OSM could go a lot further in that 
> direction, and should strive to do so. That needs strategic high-level 
> decisions. If cartographic renderings becomes a priority, other design 
> decisions will follow. Now when many other factors are of higher priority, no 
> improvement will happen.

We agree that OSM "can go a lot further in (those directions)."  We DO strive 
to do so, however, there are processes like consensus and running on a 
shoestring budget by volunteers which are unique to OSM (and open projects) 
that many consider slow, even messy.  (Sort of like the democratic process in 
the USA?  But hey, see?  EVENTUALLY, good things DO happen!)  How OSM 
"prioritizes" what is important is likely the closest resonance to what you 
call "anarchistic," as everybody has their favorite priorities and it can be 
slow going to find unity so that the betterment of the map (and how it works, 
how it looks, how it acts...) "lurches" forward.  Heck, forward momentum is 
terrific as it happens, even if it took a while to get there.

> I will continue to be a casual mapper as long as the bike routing tools I use 
> use OSM. I'm an egoistic contributor in that regard, I do it because I need 
> have direct use for the data myself. I also map the places I grew up in and 
> love, and I have a specific connection to rural areas (although I live in 
> city now) so I do work there to, makes me feel good. Some do handicraft as 
> relaxing hobby, and mapping is my handicraft.

This puts you right in the wheelhouse of a great many other OSM mappers who 
share a virtually identical profile as you:  you can consider yourself among 
"birds of a feather" as a part of OSM in those regards.  Welcome.

> As I described in a different post, here in Sweden OSM doesn't have a 
> particular strong position as the alternatives has come strong the past 5 - 7 
> years. OSM didn't reach a good baseline here before interest went down due to 
> easily and cheaply accessible alternatives, so we are in a tricky situation. 
> We need mappers and it's hard to convince regular people to contribute to 
> OSM, "why do that when high quality maps are free?". I've written open-source 
> software since the 1990s, so the open license thing is an easy sell to me, 
> but to regular people the ideology bit doesn't really work. I haven't done a 
> survey, but my theory is that the typical contributor here do it as a sort of 
> pleasing handicraft.

Consider that while OSM "chugs along" (slowly? maybe...) compared to other 
(nearly always commercial, proprietary) concerns, we do so with the truly 
long-term goal of "keep the data open and free."  Others, while they certainly 
have their place, don't.  Indeed, consider how OSM's campaign of "Switch2OSM" 
was inspired to help web developers "wean away" from what might be called the 
commercial world's "bait and switch" approach of "give them some free samples 
to taste, then when they're hooked on how neat it is to benefit from the 
commercial product, charge them serious money."  This was found off-putting 
(offensive) to many who felt betrayed and OSM was all-too-happy to welcome them 
with open arms, so long as our long-term goals of "keep the data open and free" 
are respected.  That's a powerful lesson for open data and it will be repeated 
in the future again and again as OSM's strengths become apparent and the latest 
"flash in the pan" commercial mapping software service decides their business 
model targets YOUR wallet to pay for its profits, rather than earning the 
respect of your community (both OSM and not) for the modest efforts we expend 
as volunteers.  Long-term, OSM co-exists with these other map data providers, 
but we each do have our places in the geographic data ecosystems of the world.  
"Regular people" don't need to understand these mighty forces to have the 
everyday experience of "I wanted a better map of my neighborhood, so with a 
modest amount of effort, I did so."  You can change "I" to "we" with two, three 
or larger numbers of people, too, as OSM works very well in small groups of 
dedicated volunteers who share passion for a locality or region — we really do 
get a great deal done exactly like that.

> To make it pleasing the resulting product should be good, and I think there 
> is more to do there, not the least for rural areas where the naming issues is 
> most evident.

Yes, there is ALWAYS "more to do" in OSM.  Consider this:  "the map is

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

One more thing to consider: generalisation is one of the most
important things for cartography, but it is also extremely important
for vector tiles. 2-3 years ago we've played with government data and
it produced huge (up to 4MB) vector tiles (pbf) for middle scales
(zoom 8-12). Browsers (especially mobile ones) were struggling with
that amount of data. Even moderate generalisation reduced the amount
of data to 0,5M. It is something which is currently brushed under the
carpet as using raster will never produce a tile that large. What I'm
saying here is that generalisation (the real one, not DP) will have to
be done anyways as OSM community is starting to see the disadvantages
of legacy raster maps and is getting used to the idea of vector maps
(for the client, not between servers).

2020-11-07, št, 21:23 Anders Torger rašė:
> (I had to run it in Chrome, it didn't render properly in my Firefox, but
> this vector stuff is new tech and Linux Firefox seems to have some
> issues with that.)

  Strange. Firefox on linux is my primary browser, it is the way I
always use/test *.openmap.lt...

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

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


Hello Tomas,

I just need to comment specifically on your https://topo.openmap.lt -- 
I'm very impressed!


(I had to run it in Chrome, it didn't render properly in my Firefox, but 
this vector stuff is new tech and Linux Firefox seems to have some 
issues with that.)


/Anders

On 2020-11-07 07:52, Tomas Straupis wrote:

  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.


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

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

Yes, maps are definitely primary way how OSM data is used.

I just wanted to note that it is not only way how it is used.


Nov 7, 2020, 19:42 by and...@torger.se:

>
> Yes good point. Actually, I don't even know if cartography makes the top ten 
> list of how OSM data is used. Does it?
>
>
> For me personally cartography is *the* thing, and I guess I am guilty for 
> arguing from my own perspective. Sure I use basic road routing capabilities 
> too that stem from the data, but what makes it satisfactory for me to map 
> more than just basic roads (which I indeed do a lot of) is that I see my data 
> resulting in good looking and useful cartography (which today leaves some 
> basic key things to be desired in my humble opinion).
>
>
> On 2020-11-07 16:50, Mateusz Konieczny via Tagging wrote:
>
>
>>  
>>  
>>  
>> Nov 7, 2020, 16:41 by and...@torger.se:
>>
>>> And in the end it's about the resulting map.
>>>
>> Not only, OSM data is also used in other ways.
>>  
>>
>> ___
>> 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?


Yes good point. Actually, I don't even know if cartography makes the top
ten list of how OSM data is used. Does it? 


For me personally cartography is *the* thing, and I guess I am guilty
for arguing from my own perspective. Sure I use basic road routing
capabilities too that stem from the data, but what makes it satisfactory
for me to map more than just basic roads (which I indeed do a lot of) is
that I see my data resulting in good looking and useful cartography
(which today leaves some basic key things to be desired in my humble
opinion). 


On 2020-11-07 16:50, Mateusz Konieczny via Tagging wrote:

Nov 7, 2020, 16:41 by and...@torger.se: 


And in the end it's about the resulting map.


Not only, OSM data is also used in other ways. 


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

Sorry for replying to myself again, but I realized the link I shared was 
not a true example, although the maps I linked to are built to look 
similar to vector data they are delivered as png tiles, and least on my 
computer (some services switch automatically between pixel/vector).


This link (of another Swedish provider) should lead to a true vector map 
(which runs superduperslow on my old computer):


https://www.hitta.se/kartan!~59.39246,17.88950,10z/tr!i=COl8SQsO

It's using the same government data source as the eniro website, but 
unfortunately this one only has Sweden, not Norway and Finland.


Interestingly enough it has another type of label algorithm that works 
worse than the old pixel map in rural areas (ie you need to zoom more 
than usual to see names). However this vector technology and 
presentation is very newly introduced so I expect it to be refined over 
the coming years. Personally I prefer the pixel renderings still as 
vector is a bit slow on many computers. But it's the future


On 2020-11-07 17:45, Anders Torger wrote:

Here's an example of vector maps for Norway, Sweden and Finland as
presented by a popular Swedish address lookup service:

https://kartor.eniro.se/?c=59.370292,17.690735=9


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

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


Thanks for those valuable points.

I'm a layman, watching at OSM form the outside as a casual mapper and 
user. You're an expert on the inside. My perspective is thus limited, 
and also limited is the understanding of technical and infrastructure 
challenges.


Regarding of comparing to government maps, I'm a bit sorry for putting 
that as a strong focus, it varies very much between countries the 
quality of this data and how it's presented etc. It's just that for me 
it's a central reference tool when making maps, and the OSM tools is 
actually preloaded with some of their maps.


As an amateur mapper I think it's a good idea to look at professional 
cartography to see how naming are solved, and as I currently map 
locations I am very familiar with myself I actually know the names and 
how they are used, so I'm not just copying from the map. I maintain that 
the naming issues the thread started with are very real and relevant, 
and I think it is a problem that they cannot properly be addressed in 
the current infrastructure. If manual placement of point tags with 
manual prominence sorting rather than actual mapping of named areas is 
the better choice in practice, so be it. I'm the layman, you're the 
expert. I just see a problem and want it solved, somehow.


However if the problem is that there is actually no widespread interest 
to improve in these areas or maybe even OSM shouldn't be used in this 
way, then ok. I'll know. A key reason for starting this discussion was 
to feel the pulse where this is going. If OSM is not meant to make 
cartography to the level I desire, and my desire is just seen as a tiny 
niche interest, then I know this is a dead end. It does diminish the 
satisfaction of my own mapping as cartography is one of my driving 
forces, but I cannot pretend that everyone is like me. I just hope that 
there are some other cartography fans out there that also like to see a 
move in this direction.


The thing about falling behind, I'm guilty of that narrative, and I've 
mentioned google maps as one of the main threats (which I think is a 
realistic scenario), but what it's actually about is that I think OSM 
has become a bit too stagnant as does not seem to be able to adapt to 
changed situations and may risk become obsolete in developed countries. 
I put great importance to cartography here, which perhaps is a 
misjudgment (ie maybe just my own personal niche interest), but the 
reason I do it is because I believe many contributing mappers see that 
as important and makes it more pleasing to contribute, and what OSM 
needs is contributions, and especially so in Sweden where we are very 
much behind indeed (not behind Google maps though, which still is kind 
of bad...). I don't want to disrespect or anything like that, it's just 
a genuine worry from someone who wants OSM to succeed and grow and 
become good where I live.


About quickly throwing overboard all values, I think one problem is that 
this community has become so sensitive that every hint of someone 
suggesting that something needs a change is interpreted as a direct 
threat. It's not my intention. I don't think we need to throw overboard 
all values, but I think there is a need to make adjustment due to the 
huge size and diversity of the community and the increased technical 
complexity, and the need to involve and manage more commercial 
interests. I think some centralized elements are required, and OSMF 
board probably need to be somewhat more involved in strategy.


And I don't think we can use a process which takes 4 - 8 years to 
implement basic features, if some of those basic features are still 
missing 16 years into the project. I mean those names that brought up 
all this are hundreds of years old. It's not a new fashionable thing 
that a map needs to have one name for several entities. It's not a new 
thing that hills and valleys of varying sizes have names, etc. Sure 
there are things that are fashion of the day, and it's a good that the 
overall structure is conservative. I just get a sense that regardless of 
suggestion made, someone will immediately say in some way or another 
that change is impossible, and to me that is a bit worrying.


/Anders

On 2020-11-07 15:34, Christoph Hormann wrote:

I wanted to quickly comment on two things where a misleading narrative
seems to be represented in the discussion here so far.

The first one is the idea that OSM community cartography is being held
back by the lack of computing power.  It is not.  The resources that
would be required to run various data preprocessings that have from
time to time been considered in map style development are absolutely
negligible compared to the ressources used by the OSMF for rendering
and tile delivery.

The problem is process development and maintainance.  I have -
together with Jochen - from 2015 to 2019 operated
openstreetmapdata.com where we offered various preprocessed OSM data
for cartographic applications updated daily and we

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


Hello Steve,

thanks for that wonderful and inspiring post! I'll surely think about 
doing-what-can-be-done-with-the-current-tools-at-hand, and think about 
that the work can be built upon by others in the future. Most inspiring!


And I'll also clarify, I don't expect some Swiss cartographic artwork to 
come out of the renderer. But I do think that OSM could go a lot further 
in that direction, and should strive to do so. That needs strategic 
high-level decisions. If cartographic renderings becomes a priority, 
other design decisions will follow. Now when many other factors are of 
higher priority, no improvement will happen.


I will continue to be a casual mapper as long as the bike routing tools 
I use use OSM. I'm an egoistic contributor in that regard, I do it 
because I need have direct use for the data myself. I also map the 
places I grew up in and love, and I have a specific connection to rural 
areas (although I live in city now) so I do work there to, makes me feel 
good. Some do handicraft as relaxing hobby, and mapping is my 
handicraft.


As I described in a different post, here in Sweden OSM doesn't have a 
particular strong position as the alternatives has come strong the past 
5 - 7 years. OSM didn't reach a good baseline here before interest went 
down due to easily and cheaply accessible alternatives, so we are in a 
tricky situation. We need mappers and it's hard to convince regular 
people to contribute to OSM, "why do that when high quality maps are 
free?". I've written open-source software since the 1990s, so the open 
license thing is an easy sell to me, but to regular people the ideology 
bit doesn't really work. I haven't done a survey, but my theory is that 
the typical contributor here do it as a sort of pleasing handicraft.


To make it pleasing the resulting product should be good, and I think 
there is more to do there, not the least for rural areas where the 
naming issues is most evident.


/Anders

On 2020-11-07 13:30, stevea wrote:

On Nov 6, 2020, at 1:51 PM, Anders Torger  wrote:


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

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

A move to prioritize cartography is probably not easy and there are lots 
of challenges. But I think it can be much better than it is today.


I'm not too surprised that people in general would prefer google map 
with less information. The thing with cartography designed for paper is 
that it's extremely dense as you need to present all the information you 
can on a single page (you can't zoom), and being used to zoomable map 
seeing a map designed for paper can be a bit of a shock. Many of these 
government maps which are zoomable like your beautiful 
https://map.geo.admin.ch example is not actually a single map, but all 
the purpose-made maps at different scales, so each zoom level is meant 
to be used on its own, printed on paper.


Probably that is not how OSM should work, and here in Sweden the 
government maps are now starting to appear in zoomable vector format and 
they work a bit differently, and look a bit less dense. The information 
is there though. Personally I like the art of cartography so I like the 
look of those traditional dense maps, but I also understand that a 
digital map may need to be a bit different.


Here's an example of vector maps for Norway, Sweden and Finland as 
presented by a popular Swedish address lookup service:


https://kartor.eniro.se/?c=59.370292,17.690735=9

They use government-provided data for all three countries. If you ask me 
I think it's a small step back compared to traditional cartography, 
example of that here:


https://kso.etjanster.lantmateriet.se/?e=657065=6568677=7=default_background_noauth

But I understand it's a matter of taste, and in any case the less 
designed and more automatic vector maps is the future, and it's also 
more suitable presentation format for the OSM data.


However, if the community actually don't see that there is any problem 
with how the current OSM data is presented and do not want any change, 
so be it. I'm just a tiny part of the OSM community and I'm not here to 
tell what we as a whole should do, just voicing some opinions.


I am however a bit afraid that the community due to its size has become 
unable to make strategic decisions, and I do believe that if OSM 
continues to be stagnant (which to me as a semi-outsider it appears to 
be), it will lose its position and fall into being a niche product at 
least in the developed countries. I think for example that Google Maps 
will develop quite significantly in the coming decade, both in data 
density and presentation. I think there's a very real risk that they 
will replace OSM in many places OSM is strong today. That would be sad, 
but end users don't really care if it's an open license or Google owns 
it, as long it's "free" to them they go for the best map.


Locally here in Sweden we have the problem that OSM data is lacking in 
large parts of the country, combined with some strongly varying quality 
imports (imports is a whole other subject...), so we have a lot of 
mapping and fixing to do before we have a reasonable baseline, so it 
doesn't have a strong position today. OSM is still being used here as a 
side effect of international services using OSM, like facebook and 
various routing tools.


I personally use plotaroute for my bike rides, and that was actually how 
I got into being a mapper, I needed to fix the maps to be able to draw 
the route, I also like the fact that I can add off-road tracks which 
aren't really available in normal maps, plus responding immediately to 
rebuilds in the city (which happens a lot during recent years). But 
noone here uses OSM for car navigation, the map is not good enough and 
there are other maps that provide that with 100% coverage. 10 years ago 
good map data was very expensive here in Sweden, nowadays it's not the 
case (except for some special uses), so regular users just choose the 
best map, cost is not an issue. And the result has become that OSM is 
normally only chosen if it's the only map a specific service uses, and 
one needs to use that particular service. Or if one like me is a mapper, 
but I consider that to be a niche. I don't know anyone except myself 
that contribute to OSM here. With my ~10 days active per year I'm top 15 
mapper in the country, which says that OSM is not a huge thing here.


In other words, I look at OSM from a perspective where it does not have 
a strong position today, and that it's free with open license 
unfortunately doesn't mean much here. The only thing that means 
something is the product the end user sees.


/Anders

On 2020-11-07 12:47, Tomas Straupis wrote:

2020-11-07, št, 13:24 Anders Torger rašė:

However, and this is a big however, I think that the face of
openstreetmap really need to be a cartographic sound map.


  During personal meetings as well as during different presentations
in conferences I've been showing people two maps (one was google,
another one was swiss topo https://map.geo.admin.ch). Google is one of
the worst (from cartographic perspective) and Swiss topo

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




Nov 7, 2020, 16:41 by and...@torger.se:

> And in the end it's about the resulting map.
>
Not only, OSM data is also used in other ways.

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

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

Probably the database should be organized in layers. The more 
information there is, the messier it becomes to have everything visible 
at once. With JOSM you can sort of simulate layers with filters on tags 
(I use that feature all the time), so I'm not sure if it actually needs 
to be layers in the database or if it just needs to be adaptation on the 
tools side.


I disagree that names in the landscape is of little value, and actually 
defining what it is covering is providing additional value over just 
placing a point, and I think is opposite to tag for the renderer.


And in the end it's about the resulting map. The current use of points 
won't do what's required to be able to make good cartography.


/Anders

On 2020-11-07 13:01, Frederik Ramm wrote:

Hi,

On 11/6/20 19:31, Anders Torger wrote:

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


This is an absolute pain for me. We're seeing people define
ultra-precise multipolygons of various sizes with the single purpose of
getting a name rendered somewhere in a bay.

If this infects other areas of cartography, we'll see people build
thousand-node polygons for vaguely defined land areas ("the XY
lowlands", "the XY mountain range", "the XY plateau"). This is a very
sad development that makes editing more complicated and burdens the
database with information of very little value.

What people want to achieve is some lettering on the map, and because
the only way to get that is making huge polygons that purport do
describe the exact extent of something, that's what they do.

I think this needs to be stopped. We've created a
mapping-for-the-renderer mechanism by the back door. This is actually
*worse* than if we were to allow people to place a point somewhere and
annotate it with a desired label font size and orientation. Not that I
would advocate the latter, but what we have now has all the negative
features of the latter *plus* the side effect of creating giant,
unmaintainable polygons.

Bye
Frederik


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

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

2020-11-07 Thread Seth Deegan

I actually just found that article about OSM’s problems.

One of the major topics mentioned, the fact that OSM acts as a database and
not a map, and that this acts as a hinderance to the expansion and
development of the project, is very true.

As a result, I’ve came to think that implementing Vector tiles should be
OSM’s #1 development priority right now. If people who find OSM realize
that there’s a lot more data than just the raster images displayed by the
standard tile layer, than they will be more likely to contribute and grow
the OSM community.

We’re all here complaining about computational needs required by rendering
servers, but there are some great vector tile implementations that require
way less computational needs.

Moral of the story: We need Vector tiles.

El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger 
escribió:

> This is great information, I didn't know about your project, very very
> interesting. I have recently come to understand the OSM-Carto technical
> challenges recently. I haven't given it much of a thought as a casual
> mapper for the past two years, just been a bit disappointed with how it
> looks.
>
> I am a programmer in profession though so when taking a deeper look and
> though about it I see these challenges.
>
> However, and this is a big however, I think that the face of
> openstreetmap really need to be a cartographic sound map. It's not right
> that a style seemingly designed mainly for speedy diagnosis should be
> the face of OSM. How many of our mappers are so technical that they
> understand this? And howcome did I not even know about this cartographic
> project of yours? If there are great styles out there but noone knows
> about them that's a problem.
>
> And even if we let the not-so-good-cartography be the first map we see
> on openstreetmap.org (which makes no sense), some of the other layers
> presented there should be one which focus on good cartography, and all
> that are there now have many of the same issues as the main style.
>
> I assume that many, perhaps most, casual mappers use the web editor. I'm
> really impressed with the web editor, it's great and is mostly
> user-friendly, you don't need to be a technical person to map, and that
> is how I think it should be. One thing with the web editor though is
> that unless you are technical enough to turn off caching (which
> essentially means putting the browser in development mode), you won't
> see the rendered results for a long time, even if reloading the page,
> you still get cached data. Thus it wouldn't matter if the rendering
> wasn't updated for a couple of hours or even more, the casual mapper
> won't see it anyway.
>
> I think that direct feedback is desirable of course, but compared to
> other goals I think it's less important, and one can work with the user
> interface in the web editor to mitigate this issue. Perhaps just have a
> way to probe the server so it can deliver some render status. The
> biggest problem today with the web editor regarding feedback is that to
> a casual mapper it may not be obvious that the map needs to be rendered
> at all and that can take time, and together with the web caching and
> different zoom levels it gets even more confusing. Many of us more
> experienced mappers know exactly how OSM works and renders, and we go
> blind for how a new user will experience it.
>
> One way to mitigate this could be to turn on some render info view in
> the web interface to show render status of tiles, maybe even estimated
> time left, and then a way to refresh the tiles without having to resort
> to putting the web browser in development mode with disabled cache.
>
> And now to the most important point, whether one likes it or not,
> OSM-Carto as being the face of OSM and the most commonly used style, is
> the de-facto reference and driver of features and tagging. If OSM-Carto
> doesn't support basic cartography features many mappers won't be
> motivated to tag for that, and then the cartographic styles will have
> less information than they need to make good maps. OSM-Carto due to its
> limited rendering capabilities also make casual mappers tempted to "tag
> for the renderer" just to get results, which for example can mean that
> villages are upped, and thus the cartographic style will get fed with
> incorrect information.
>
> In summary I think there are *very* strong arguments for that the main
> style shown at openstreetmap.org and the main style used for editors
> should be focused on providing great cartography (with the extension
> that it should probably present more features than a usual map,
> alternatively we need to split into several styles, all cartographic
> sound), and we must allow it to be be more computationally expensive and
> come up with smart ways to mitigate that in the tools. We can't
> stubbornly hold on to principles and use the same arguments that held up
> and worked well back in 2004, there are things that need to be revised.
> And one of

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

2020-11-07 Thread Christoph Hormann

I wanted to quickly comment on two things where a misleading narrative seems to 
be represented in the discussion here so far.

The first one is the idea that OSM community cartography is being held back by 
the lack of computing power.  It is not.  The resources that would be required 
to run various data preprocessings that have from time to time been considered 
in map style development are absolutely negligible compared to the ressources 
used by the OSMF for rendering and tile delivery.

The problem is process development and maintainance.  I have - together with 
Jochen - from 2015 to 2019 operated openstreetmapdata.com where we offered 
various preprocessed OSM data for cartographic applications updated daily and 
we offered to develop additional processes and extend this with additional 
processed data offers in case people were willing to invest in that.  The 
interest in both the existing data sets as well as in developing new ones was 
extremely sparse.

And any such process needs aintenance obviously - the costs of which by far 
exceed those of the computing infrastructure.

I have during that time and since then done quite a bit of customized 
cartographic data processing for map producers but none of them was ever 
interested in actually financing open source process development in that 
domain.  Hence the work i have done there stays proprietary technology.

The bottom line is neither in the hobbyist OSM community nor among commercial 
OSM data users is there a substantial interest in investing in technologically 
advancing quality in automated rule based cartography based on generic geodata 
like in OSM.  The bays and straits Frederik discusses are a good example.  Both 
mappers and corporate data users seem much more keen in crowd sourcing the 
drawing of labeling polygons to the cheap labor of the mapping community than 
to invest into development and maintenance of open source processes to derive 
importance rating and labeling geometries from bay and strait nodes and 
coastline data.  The irony is that compared to some other problems of automated 
cartography based on OSM data (river networks just to mention one) this is not 
even close to rocket science.  With a 10-20k investment you could achieve quite 
a lot in this field (which is already now far less than the sum of work hours 
at minimum wage invested by mappers into drawing and maintaining labeling 
polygons).  This is just an example of course - there are many other fields.

The second thing i want to comment on is the yet again resurfacing story that 
OSM is falling behind compared to  - in this case government mapping.  And 
therefore we all quickly need to throw overboard all values and traditions of 
the project and urgently become more like .

Such calls are universally based on a lack of understanding of what 
OpenStreetMap is and how OSM became what it is today.  Yes, OpenStreetMap has 
deficits it needs to improve on (i discussed one of them above) but throwing 
overboard valuable lessons learned from the past and throwing ourselves at what 
seems to be the hype of the day is not going to solve anything.  Focusing on 
what OSM is good at and what has made and makes it successful as a social 
project, the cooperative collection of verifiable local geographic knowledge, 
is the key.  That requires a certain technological, communicative and yes, also 
cartographic context and to be and stay avant-garde in that context.  But 
trying to imitate for example what government mapping agencies do (who are 
universally still pretty much stuck in mere 1:1 digitalization of traditional 
pre-digital processes), or on other fronts:  what big corporate map producers 
do for cost efficient production of mediocre maps for social media platform 
customers who don't care a bit about cartographic quality, is definitely not a 
long term winning strategy to do that.

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

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

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

2020-11-07, št, 14:37 Jeremy Harris rašė:
> Alternatively, could the rendering job be done by the client needing the
> out-of-date tile, and resubmitted to the server?

  As Mateusz has pointed out, this has already existed, but one of the
reasons it was discontinued (along with the lack of interest) was that
it meant you're rendering and rerendering a lot of tiles which nobody
needs. Renderer must be connected to actual usage of the map.

  Another thing with rerendering (and it actually is a problem for
both client and server rendering) is segmentation. When doing
generalisation a lot of things aggregate, so even when nothing changes
on your particular square (data-wise), result could change because of
changes in neighbouring squares. There are a lot of segmentation
strategies to be used depending on types of objects being worked on
(and types of generalisation operations being performed on them), but
it is not as simple as current usage with osm2pgsql generating dirty
tile list.

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

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




Nov 7, 2020, 13:33 by j...@wizmail.org:

> On 07/11/2020 11:13, Walker Bradley wrote:
>
>> Computing power seems to be a constraint struggle without greater 
>> fundraising capacity, so could there be some work done on the rendering 
>> process? Could we do a specific and targeted fundraising effort to improve 
>> the renderer to make as much use of the limited computer power we have?
>>
>
> Alternatively, could the rendering job be done by the client needing the
> out-of-date tile, and resubmitted to the server?
>
(1) you need trusted clients (as client can submit any image and claim that it
is a generated map)
(2) administering thousands of clients is very problematic and time consuming
(3) it existed as tiles@home and stopped existing as noone was interested in
maintaining this

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

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

2020-11-07 Thread Jeremy Harris


On 07/11/2020 11:13, Walker Bradley wrote:

Computing power seems to be a constraint struggle without greater fundraising 
capacity, so could there be some work done on the rendering process? Could we 
do a specific and targeted fundraising effort to improve the renderer to make 
as much use of the limited computer power we have?


Alternatively, could the rendering job be done by the client needing the
out-of-date tile, and resubmitted to the server?
--
Cheers,
  Jeremy

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

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

2020-11-07 Thread stevea

On Nov 6, 2020, at 1:51 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.

Anders, you make many excellent points.  You also seem ambitious and there is 
nothing wrong and everything right about that.  Well-done cartography that is 
at a “gold standard” level of quality often DOES take professional, “old 
school” cartographers (and / or their methods and technology base, whether long 
printing toolchains, serious drafting and actual cartography skills, or similar 
things).  OSM rather “democratizes” that process to the level of individuals 
who can do everything from add a simple POI (or even simper, a POI update) to 
the map and perhaps “be done” with that contribution.  Even if small, no 
contribution that adds value to OSM is unwelcome or TOO small.

However, to really “improve an area” (to make a slice of OSM suitable as a 
general-purpose map for a wide variety of “many citizens”) is a deep, 
time-consuming, technologically involved process.  Myself and many so-called 
“craft mappers” who both wish to and actually do add such deep, long-term 
quality to the map (in the form, mostly, of “improving our own areas”) have 
been busy doing this for six, ten, twelve years or even longer in OSM.  Some 
(having started more recently) of us are well on their way after just as many 
months, becoming so enthused by the project that we decide to engage with a 
rewarding activity and keep at it for many years.  Others still decide that 
ambitions exceed their time or ability and manage to contribute exactly what 
they are able to contribute, and do, while their ambitions remain “on a back 
burner,” or maybe get channeled into community-building with other volunteers 
who complement each other's skills and benefit from the “magic multiplier” of 
crowdsourcing.

However, there are no “magic wands” one might wave that guarantee “reasonable 
chances of success” at a workload that is acceptable and sustainable for any 
given individual.  There are only one’s efforts over the short, medium and 
longer terms which achieve such good (quality) results.  And the satisfaction 
of knowing that others do so, too, and we are stronger, better and a wondrous 
map of “we” as we do so.

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

Good!  That sort of spirit is exactly what fuels OSM.  Yes, it is “extremely 
ambitious,” yet “tall mountains beg to be climbed."

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

I’m sorry to hear that it’s too much for you.  I’d rather hear that it MIGHT be 
too much for you, as then “your door remains open” to contribute SOMEthing that 
might channel your awesome ambitions into shoulders that others might stand on 
to grow the map taller into the future.  For example, you might consider a 
“skeleton” approach (hills as natural=peak or perhaps natural=ridge with names, 
both of which render).  These can offer a rough sketch that others in OSM can 
use to build upon later, adding natural=wood, scrub, bare_rock, glacier, islet, 
amenities, roads (highways) and so on.  I DID mix up a bunch of keys and values 
right there (a key+value is often called a tag) as these are the sorts of 
“alphabetic basics” that make up OSM.  Learning these, how to use them, how you 
might propose changes to them (though, this isn’t

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

2020-11-07 Thread Yves via Tagging



Le 7 novembre 2020 12:47:45 GMT+01:00, Tomas Straupis  
a écrit :
> Fuzzy features (like
>continents, mountain ranges, bays etc. should probably be moved to a
>separate database).
>
I often thought an 'Openlabelmap' database containing geometries to help with 
the labeling of such features could help solving the issue of mapping this 
larges or fuzzy geographical places the same manner we can map a bench or a 
road.
Yves 

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

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

2020-11-07 Thread Frederik Ramm

Hi,

On 11/6/20 19:31, Anders Torger wrote:
> ** 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.

This is an absolute pain for me. We're seeing people define
ultra-precise multipolygons of various sizes with the single purpose of
getting a name rendered somewhere in a bay.

If this infects other areas of cartography, we'll see people build
thousand-node polygons for vaguely defined land areas ("the XY
lowlands", "the XY mountain range", "the XY plateau"). This is a very
sad development that makes editing more complicated and burdens the
database with information of very little value.

What people want to achieve is some lettering on the map, and because
the only way to get that is making huge polygons that purport do
describe the exact extent of something, that's what they do.

I think this needs to be stopped. We've created a
mapping-for-the-renderer mechanism by the back door. This is actually
*worse* than if we were to allow people to place a point somewhere and
annotate it with a desired label font size and orientation. Not that I
would advocate the latter, but what we have now has all the negative
features of the latter *plus* the side effect of creating giant,
unmaintainable polygons.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

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

2020-11-07, št, 13:24 Anders Torger rašė:
> However, and this is a big however, I think that the face of
> openstreetmap really need to be a cartographic sound map.

  During personal meetings as well as during different presentations
in conferences I've been showing people two maps (one was google,
another one was swiss topo https://map.geo.admin.ch). Google is one of
the worst (from cartographic perspective) and Swiss topo is one of the
best (Generalisation book of Swiss cartographers is like a magic
book). And surprisingly (or not) a lot of people still prefer google
style maps (at least for on-screen maps where you can zoom). In this
year's SOTM Baltic the audience was split roughly 50/50 between
google/swiss topo. So it is not clear which is better even if we do
not think about technical difficulties.

> And howcome did I not even know about this cartographic project of yours?

  Because it only covers Lithuania, because it is done as part of
Lithuanian fellowship of cartographers, not international.

> I assume that many, perhaps most, casual mappers use the web editor.

  Most edits are done with the main OSM editor which is - JOSM.

> I'm
> really impressed with the web editor, it's great and is mostly
> user-friendly,

  And is very prone to damage good data. We (in Lithuania) encourage
everybody to switch away from iD as soon as possible.

  Also note that cartographic style needs even more stuff, not only
hardware and ideas (most generalisation tasks are not solved because
algorithms are not designed/crystalised, coding is the least of the
problems). In order to do good cartography you would have to agree on
a much stricter use of tags and sometimes push some things into
tagging which a lot of participants of this mailing list could
disagree - for example road network hierarchy. Fuzzy features (like
continents, mountain ranges, bays etc. should probably be moved to a
separate database).

-- 
Tomas

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

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

Others can correct me if I'm wrong, but I think the problem is not
really limited computing power, but it's a design thing. Update speed
has a really high priority, too high if you ask me. So regardless of
computer power available, we want the fastest update speed possible.

For the main servers, as far as I understand they have ready-made tiles
basically for the whole world. So there's always a tile ready to serve.
When a database update comes in and a tile needs updating the old tile
will continue to serve normally until the new is available. To give
casual mappers feedback quickly we like this to happen fast. However as
the web browsers cache data the mapper may see old data for a long time
anyway, so I don't really think update needs to be fast (instead the
user interface needs a mechanism to provide the mapper with progress
information of the rendering), and then we can switch algorithms to more
advanced and slower ones which focus more on cartography and less on
speed.

However (this is a bit of my guesswork, I haven't read up 100% on this)
then we have all those private small servers serving tiles. In this case
the hardware is quite simple and inexpensive and there's no practicality
in having pre-made tiles for all the world, so you need to render
on-demand. In this case it's of course of key importance that these
tiles render really quickly or else the map simply won't appear when you
browse to view it.

I think what OSM needs now is that the main style presented to end users
and mappers should be one with more expensive algorithms and a high
focus on making the best possible cartography, and also focus on
supporting all necessary features so mappers are motivated to tag the
data correctly and detailed (ie we have some need in naming groups and
areas etc previously discussed). This will be considerably slower to
render and possibly quite difficult to develop.

Then a computationally fast style could still be maintained for the
on-demand use case. If we're smart we make them look similar, so the
fast style could be used on-demand and trigger a background process with
the slow style that fills up the area in time, as the map is generally
viewed again in the same place.

On 2020-11-07 12:13, Walker Bradley wrote:

Dear all,

First off I would like to state how fascinating this conversation is. I've been working with OSM data for years, and I never understood how the rendering actually worked. It seems like the challenges are two-fold. One is computing power and the other seems to be rendering algorithms.

Computing power seems to be a constraint struggle without greater fundraising capacity, so could there be some work done on the rendering process? Could we do a specific and targeted fundraising effort to improve the renderer to make as much use of the limited computer power we have? How much would such an endeavor actually cost and how would one go about organizing that?

On Nov 7, 2020, at 10:36, Anders Torger wrote:

Sorry, I'm no expert so I should have been more humble and not state it as a "fact". I *think* multipolygon was supposed to be a way to make single entities of complex shapes, and these groups are not really single entities, but multiple entities with single names, and thus I find it "superior" to have a specific tag for that. I'm satisfied with using a multipolygon though, and that is what I do now. This group naming is fairly common where I map that I need it now and can't wait until some unspecified time in the future when a specific group tag might be rendered.

I suppose you could turn the argument around and say that it's better to use multipolygon and not add bloat with a specific tag. And when the state is as it is, the multipolygon way is the closest to actually do what we need, I can agree with that. I'm all for results.

/Anders

On 2020-11-07 06:57, Mateusz Konieczny via Tagging wrote:

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

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

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

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

This is great information, I didn't know about your project, very very 
interesting. I have recently come to understand the OSM-Carto technical 
challenges recently. I haven't given it much of a thought as a casual 
mapper for the past two years, just been a bit disappointed with how it 
looks.


I am a programmer in profession though so when taking a deeper look and 
though about it I see these challenges.


However, and this is a big however, I think that the face of 
openstreetmap really need to be a cartographic sound map. It's not right 
that a style seemingly designed mainly for speedy diagnosis should be 
the face of OSM. How many of our mappers are so technical that they 
understand this? And howcome did I not even know about this cartographic 
project of yours? If there are great styles out there but noone knows 
about them that's a problem.


And even if we let the not-so-good-cartography be the first map we see 
on openstreetmap.org (which makes no sense), some of the other layers 
presented there should be one which focus on good cartography, and all 
that are there now have many of the same issues as the main style.


I assume that many, perhaps most, casual mappers use the web editor. I'm 
really impressed with the web editor, it's great and is mostly 
user-friendly, you don't need to be a technical person to map, and that 
is how I think it should be. One thing with the web editor though is 
that unless you are technical enough to turn off caching (which 
essentially means putting the browser in development mode), you won't 
see the rendered results for a long time, even if reloading the page, 
you still get cached data. Thus it wouldn't matter if the rendering 
wasn't updated for a couple of hours or even more, the casual mapper 
won't see it anyway.


I think that direct feedback is desirable of course, but compared to 
other goals I think it's less important, and one can work with the user 
interface in the web editor to mitigate this issue. Perhaps just have a 
way to probe the server so it can deliver some render status. The 
biggest problem today with the web editor regarding feedback is that to 
a casual mapper it may not be obvious that the map needs to be rendered 
at all and that can take time, and together with the web caching and 
different zoom levels it gets even more confusing. Many of us more 
experienced mappers know exactly how OSM works and renders, and we go 
blind for how a new user will experience it.


One way to mitigate this could be to turn on some render info view in 
the web interface to show render status of tiles, maybe even estimated 
time left, and then a way to refresh the tiles without having to resort 
to putting the web browser in development mode with disabled cache.


And now to the most important point, whether one likes it or not, 
OSM-Carto as being the face of OSM and the most commonly used style, is 
the de-facto reference and driver of features and tagging. If OSM-Carto 
doesn't support basic cartography features many mappers won't be 
motivated to tag for that, and then the cartographic styles will have 
less information than they need to make good maps. OSM-Carto due to its 
limited rendering capabilities also make casual mappers tempted to "tag 
for the renderer" just to get results, which for example can mean that 
villages are upped, and thus the cartographic style will get fed with 
incorrect information.


In summary I think there are *very* strong arguments for that the main 
style shown at openstreetmap.org and the main style used for editors 
should be focused on providing great cartography (with the extension 
that it should probably present more features than a usual map, 
alternatively we need to split into several styles, all cartographic 
sound), and we must allow it to be be more computationally expensive and 
come up with smart ways to mitigate that in the tools. We can't 
stubbornly hold on to principles and use the same arguments that held up 
and worked well back in 2004, there are things that need to be revised. 
And one of these things is that we need to understand that good 
cartography needs priority, and good (online) cartography today has much 
tougher competition and therefore expectations than it had back in 2004.


While searching the web for what's happening inside OSM I found this 
blog post from 2018 written by a longtime OSM contributor, where some of 
these issues are discussed:

https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/

but it seems that not much has happened since, which makes me somewhat 
worried about the project's future. I don't think we need a revolution 
or something, but there are some things that need to start moving, and 
for some of these things the old processes no longer work.


/Anders

On 2020-11-07 07:52, Tomas Straupis wrote:

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

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

2020-11-07 Thread Walker Bradley

Dear all,

First off I would like to state how fascinating this conversation is.  I’ve 
been working with OSM data for years, and I never understood how the rendering 
actually worked.  It seems like the challenges are two-fold.  One is computing 
power and the other seems to be rendering algorithms.

Computing power seems to be a constraint struggle without greater fundraising 
capacity, so could there be some work done on the rendering process? Could we 
do a specific and targeted fundraising effort to improve the renderer to make 
as much use of the limited computer power we have?  How much would such an 
endeavor actually cost and how would one go about organizing that?

> On Nov 7, 2020, at 10:36, Anders Torger  wrote:
> 
> 
> Sorry, I'm no expert so I should have been more humble and not state it as a 
> "fact". I *think* multipolygon was supposed to be a way to make single 
> entities of complex shapes, and these groups are not really single entities, 
> but multiple entities with single names, and thus I find it "superior" to 
> have a specific tag for that. I'm satisfied with using a multipolygon though, 
> and that is what I do now. This group naming is fairly common where I map 
> that I need it now and can't wait until some unspecified time in the future 
> when a specific group tag might be rendered.
> 
> I suppose you could turn the argument around and say that it's better to use 
> multipolygon and not add bloat with a specific tag. And when the state is as 
> it is, the multipolygon way is the closest to actually do what we need, I can 
> agree with that. I'm all for results.
> 
> /Anders
> 
>> On 2020-11-07 06:57, Mateusz Konieczny via Tagging wrote:
>> 
>>  
>>  
>>  
>> 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
> 
> ___
> 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?


Sorry, I'm no expert so I should have been more humble and not state it
as a "fact". I *think* multipolygon was supposed to be a way to make
single entities of complex shapes, and these groups are not really
single entities, but multiple entities with single names, and thus I
find it "superior" to have a specific tag for that. I'm satisfied with
using a multipolygon though, and that is what I do now. This group
naming is fairly common where I map that I need it now and can't wait
until some unspecified time in the future when a specific group tag
might be rendered. 


I suppose you could turn the argument around and say that it's better to
use multipolygon and not add bloat with a specific tag. And when the
state is as it is, the multipolygon way is the closest to actually do
what we need, I can agree with that. I'm all for results. 

/Anders 


On 2020-11-07 06:57, Mateusz Konieczny via Tagging wrote:

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___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Hello Graeme,

the nature of these gravel yards vary a bit, but they can look like
this:

https://showmystreet.com/#12q73u_a3n0t_1v.a_-4f42

and they were made maybe 50 years ago. This one probably comes from the
time the road was straightened in the 1970s or so. But there are also
these things near say hydro power plants or other things construction,
50 - 70 years old. The thing with rural areas is that space is cheap, so
there are many of these leftover spaces from past times. And of course
there are also those that can be more easily identified as abandoned
gravel pits were raw material for the roads were taken, there the quarry
tag is more fitting.

Anyway, these are rather good to have on a map as they today serve can
serve as places to park your car or caravan when getting out into
nature.

About upping villages, I know exactly about that problem. Here it's
typical that a village consists of a few farms (nowadays most of them
inactive or at hobbyist level) and has 5 - 10 inhabitants. The villages
are quite closely spaced and kids go to school and shopping is made in a
nearby town, so it's quite nice to live here still if you like peace and
quiet :-). Anyway these type of landscapes makes the fixed sizing and
zoom visibility of name labels not work well. The names of these tiny
villages are important for navigation and you need them on an overview
map.

If you look at our official maps how they do it, they actually don't up
the villages (ie show them more prominently here in rural areas than in
the densely populated south), but instead they render the names larger
and keep them for longer when you zoom out, and when it becomes too
cluttered they have information about which names to prioritize over
others. And if you to that can name the landscape (which is limited
support for in OSM), you get a good overview map for navigation.

Here's a comparison between an official Swedish map and OSM in the same
location to show the difference in (extreme) cases:

https://www.torger.se/anders/downloads/comparison.png

In OSM zoomed out maps in these areas unfortunately just looks like
poorly designed cartography. Many of these villages are farmlands, so
they cover a pretty big area and you see them from far. There's lots and
lots of space to render name tags, but still there's no name. I
understand that this is the effect when you 1) need to have a style that
requires little processing power to render and 2) in combination need to
have the same style for 1 million people per square km and 5 people per
square km (like it is here).

I don't think the right way to solve this is to have varying style
depending on local density. What's needed is better and more
computationally costly render algorithms that can deal with larger name
tags and higher name tag density and then just have names visible from
earlier zoom levels.

However, the style of rendering has been fairly static for X number of
years, and there's no sign that this ever will be solved. Many of us
mappers just want one thing -- a good result *now*, not hope for it to
*maybe* come in 5 years. So I understand that some do tag for the
renderer, and simply up the villages.

I see s many examples of "tagging for the renderer". It's said over
and over again that you shouldn't do it, but people still do. It seems
like OSM (=we) don't understand that we can't tell people to not tag for
the renderer, if the renderer never improves. I think the map we see at
openstreetmap.org needs to show progress and improve to gain credibility
among casual mappers. Casual mappers don't know about all the technical
challenges and algorithm complexity of making a good render. They do
know how a good useful map with well-designed cartography looks though,
and in many parts of the world those are easily accessible and already
used by some online services. There is tough competition today, and if
OSM can't compete with cartography I think it will be increasingly hard
to recruit mappers, and those that do join will be tempted to tag for
the renderer to just try to come somewhat close to what the official
maps can show.

On 2020-11-06 23:22, Graeme Fitzpatrick wrote:

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

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

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

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




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?




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

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
>

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
>

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

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?

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


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

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

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?




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

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

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

[Tagging] Basic cartography features missing, why?