[Tagging] How to put a name tag on an area with more than one type?

Tue Dec 15 07:26:45 UTC 2020

Some more points after a night's sleep:

I just remembered, another issue with opentopomap is that it doesn't 
render wetland names at all, which may be a bit strange for a map with 
topology. But we could look at some other map, geofabrik for example, 
and of course it renders the same way as OSM-Carto. I don't think you 
will find any renderer, except Ture's which just implemented it in this 
thread that does this.

The thing is that this "well-established method" doesn't make much sense 
as far as I can understand. A renderer needs for each area with a name 
label scan for all adjacent areas to see which have same names. If names 
are the same it needs to calculate the area to figure out dominant 
nature type and then merge to a new area so it knows where to place the 
label. But sure, it's far from impossible. It's however strange having 
this algorithm that needs activation all the time (scanning for adjacent 
names) for still quite rare cases, and it's even more strange to leave 
it undocumented and expect that "other renderers" will implement it. But 
I'm not dumb (oh well, maybe a little) I really don't think that anyone 
believes that other renderers would implement it, it's just a standard 
argument to neutralize criticism of OSM-Carto's limited rendering. The 
answer is *always* that "some other renderer will do it properly". It's 
not exactly ideal for making progress.

I think that having limited and "soft advice" wiki documentation of how 
geodata should be interpreted and rendered is a bad idea. However I 
think it could still work *if* OSM-Carto took on the role as being a 
reference renderer rather than just an "example renderer" which does 
some things right, and other things wrong. That does not mean that 
OSM-Carto needs to have the best most advanced cartography (although it 
would be nice), it just means that it needs to properly render the 
concepts which is supposed to work. If it did, maybe we would find out 
that the algorithm for doing so is unreasonably expensive, and we would 
need to change how data is arranged or introduce a new concept (I think 
fuzzy areas is the real answer here). I think it's really risky to 
design data arrangement concepts without having an own renderer to test 
them with.

And about wasting mapper's time. What about that we have to punch holes 
and make river areas for rivers nowadays? Punch holes for waters in 
forest areas? And about wetlands, couldn't those be just rendered on top 
of forests so we didn't have to make these complex multipolygons? 
Managing multipolygons in complex nature is by faaaaar what I spend most 
time with. And imagine how much easier it would be to draw if 
multipolygons were allowed to have inners that touches outers. Now when 
you need to pull up an inner towards the outer edge, you need to change 
the shape of the whole outer multipolygon to go around. The tools 
available in JOSM for managing multipolygons is still very rudimentary. 
Split and join tools only work for the simplest cases, so you generally 
need to do these operations manually by cutting ways, making new ways 
and hand-edit the multipolygon relation. 
Simple-to-draw-but-hard-to-render multipolygons could still be converted 
to render-friendly polygons in a middle layer. Conversion and 
generalization is required regardless as soon as we move to vector 
tiles.

Personally I don't have that big issue with those multipolygons, 
although not very effective it's kind of fun to make and manage these. 
But I do note that my fellow mappers in Sweden still typically just 
ignore that forest is drawn on top of their lakes and overall that the 
multipolygon concept is just difficult to grasp for many. So if we are 
really serious about "not wasting mappers' time", we should surely look 
into ease of editing, and think twice before we introduce a new drawing 
rule that makes it more difficult to edit.

/Anders

On 2020-12-14 22:25, Anders Torger wrote:

> I certainly agree that we should not waste mapper's time, but in this 
> case it was mainly actually to make it easier for myself with JOSM to 
> find my way back to all small pieces in a fragmented landscape. Not 
> having this relation makes editing a fair bit harder as you can't 
> really see which parts belong to the same (name labels are really not 
> that visible in JOSM) and you need to click your way through or create 
> a filter on the name, but since you don't want it I will remove it. It 
> will probably lead to more work for me rather than less, but I won't 
> invent something that everyone is against. It's a value in keeping it 
> simple too. So we can put that to the side, don't worry there will be 
> no relations.
> 
> Opentopomap has some interesting features, but also it's own family of 
> problems. The largest problem (except for limited server capacity) I 
> think is that it renders borders between same tag areas, which causes 
> lots of borders of technical polygon splitting visible, which exists 
> everywhere in the map if you like it or not. The development also seems 
> to have stopped, so any issues it has now won't probably be fixed.
> 
> And does it render this "well-established method" by automatically 
> finding adjacent parts and showing only one label. I'm still waiting 
> for the result, but I would be *very* (happily) surprised if it does.
> 
> If OSM had been a normally managed project there would be numbered 
> releases of a well-defined specification how OSM data should be 
> interepreted by renderers. When there is no such thing, how can we 
> expect that other renders should solve things, without documentation?
> 
> There's so often reference to "other renderers" that does things right, 
> but where's the examples? There may be one renderer that make some 
> things right, but then others wrong (like opentopomap)... that there 
> really is no showcase renderer under the control of OSM itself I 
> personally think is the largest waste of mapper's time we do. I see 
> people skipping things, guessing, making "creative" incorrect mappings 
> just because OSM-Carto is so limited in what it can do. Not only 
> beginners, also experienced mappers. Just one example, some are so fed 
> up of that OSM-Carto cannot remove text of rivers inside lakes so they 
> cut up the river and remove the name instead. If OSM-Carto quality and 
> feature set would go up and the documentation (for mappers) with it, so 
> would the geo data, of that I'm convinced.
> 
> /Anders
> 
> On 2020-12-14 21:45, Joseph Eisenberg wrote:
> 
> Re; "Don't adjust your mapping to what you believe is most convenient 
> for data users"
> 
> I know this recommendation is unpopular with some mappers, because many 
> of us just want to see a good-looking map, and if it takes duplicating 
> relations and extra mapping work we will do it.
> 
> But remember that your time as a mapper, even though you give it to 
> OpenStreetMap freely, is actually valuable and should never be wasted 
> on doing things that can be solved by better software on the database 
> user end of things.
> 
> We should never ask 10,000 mappers to spend 10 hours a year each to add 
> something to the database which saves 10 hours of work for a database 
> user.
> 
> Sometimes this means that the rendering on openstreetmap.org [1] won't 
> look perfect, but we can expect better results in the future with more 
> advanced renderers. Consider for example how OpenTopoMap has really 
> great natural=peak and natural=saddle rendering, which uses elevation 
> and topography to adjust the rendering to look good with the contour 
> lines and different zoom levels. This is somewhat complex, but it was 
> done by an open-source, free map style.
> 
> Once upon a time I planned to add prominece=* tags to all the peaks in 
> my area so I could get good rendering results, but the solution which 
> OpenTopoMap uses is much better: it's fully automated and fast. Adding 
> the topographic prominence to every natural=peak to get better 
> rendering is a huge waste of mapper time, when you can instead 
> calculate it (or better yet the topographic isolation) at the time of 
> rendering.
> 
> Similarly mappers shouldn't map a huge relation which includes all 
> parts of the water in a long river, since it is much easier to map and 
> maintain smaller closed ways for each short part of the river water. If 
> database users need one big area, they can pre-process the data to 
> create the polygons: don't make life harder for mappers to save the 
> database users a few CPU cycles.
> 
> Your time is priceless, fellow mappers. The time of database users is 
> usually a business expense.
> 
> -- Joseph Eisenberg
> 
> On Mon, Dec 14, 2020 at 10:44 AM Christoph Hormann <osm at imagico.de> 
> wrote:
> 
>> Anders Torger <anders at torger.se> hat am 14.12.2020 15:49 geschrieben:
>> 
>> Okay, but why does the OSM-Carto renderer, and all other renderers 
>> known
>> to man(?) make multiple text labels then, when it should be a single
>> one?
> 
> OSM-Carto renders labels primarily based on the following constraints:
> 
> * due to the requirement of real time updates more complex operations 
> are severely restricted.  Clustering features, aggregating the clusters 
> geometry-wise and labeling the aggregates are such operations.
> * we want the relationship between the data in the database and the 
> rendering results to be intuitively understandable for the mapper so 
> they can derive useful feedback from the map.  That also limits the 
> complexity of data processing we can use.
> * like all zoomable interactive maps OSM-Carto has to deal with the 
> problem that high quality labeling is zoom level dependent.  At the 
> same time having different approaches to labeling at different zoom 
> levels adds a lot of complexity to the style - and OSM-Carto is already 
> one of the most complex map styles in existence.  Hence compromises are 
> made that look better on some zoom levels than on others.
> 
> As far as other map styles are concerned - i have said that before: 
> high quality cartography is expensive and the bulk of the digital map 
> market is low quality and low price - hence requires low costs.  And 
> the willingness to engage in strategic investment in methods for high 
> quality cartography in the wider OSM ecosystem as well as in the open 
> source GIS sector is so far rather small.
> 
> What can you do as a mapper:  Produce an accurate representation of the 
> geography that is non-complex in structure, is easy for you to map and 
> maintain and that is consistent with how others map things and don't 
> adjust your mapping to what you believe is most convenient for data 
> users.
> 
> --
> Christoph Hormann
> https://www.imagico.de/
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Links:
------
[1] http://openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201215/109cffb8/attachment.htm>