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

[Seth Deegan]

Thank you for the explanation Joseph Isenberg. Now I can see why that's so
hard to implement.

Also, could someone please add descriptions/organize the projects listed in
the Wiki page for Vector Tiles?
As a relative newcomer to the OSM development space, it seems that
implementing vector tiles for OSM-carto is currently the most centralized
and focused effort (though little progress) in the OSM community, yet it's
all the way down in the Server section of the article?
I'm also confused as to what the TODO section is.
The whole article is confusing at first.
https://wiki.openstreetmap.org/wiki/Vector_tiles


El El dom, nov. 8, 2020 a la(s) 11:54, Joseph Eisenberg <
joseph.eisenb...@gmail.com> escribió:

> Re: "Vector tiles could allow for instant client-side switching of map
> styles, the ability to customize the base layer, and allow users to make
> custom maps themselves"
>
> This is often claimed as a benefit of client-side vector tiles, but in
> practice it is not possible.
>
> The reason is that at mid zoom levels there is far too much data in the
> database for it all to be made available in a vector tile format so that
> the map is fully customizable.
>
> If we were to include all features on the vector tile data, the rendering
> would be too slow or would crash for many users, especially those who have
> mobile phones, or lower-powered tablets, or even current low-end laptops.
>
> Practical client-side vector tiles have to significantly simplify the data
> and remove a number of nodes and features to make the rendering practical.
> While some customization is possible (like hiding some icons and labels, or
> changing the script or language of the text labels), you are not going to
> get a custom rendering from one set of vector tiles.
>
> User pnorman and several others had been working on a demonstration which
> re-implements the current OpenStreetMap Carto style in server-side vector
> tiles (the first step), but it is quite difficult to achieve a good result
> with currently available open source tools, and there will have to be some
> compromises which worsen the cartography in some cases.
>
> I have not heard an update on this project in the past few months, so it
> may be stalled.
>
> -- Joseph Eisenberg
>
> On Sun, Nov 8, 2020 at 8:48 AM Seth Deegan  wrote:
>
>> 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.
>>
>>
>> What they mean is that the current map styles run by other providers will
>> not be necessary if we switch to vector tiles.
>>
>> Vector tiles could allow for instant client-side switching of map styles,
>> the ability to customize the base layer, and allow users to make custom
>> maps themselves (this is extremely powerful).
>>
>> This is pretty self explanatory, but I wanted to note earlier that vector
>> tiles allow for the clickability/interactivity of every element on the map.
>> Most new users who come to osm.org don't even know what the Query Tool
>> does or that it exists. It's also pretty inconvenient and slow.
>> Making everything clickable allows features to be explored with a
>> possible beautiful UI like Google Maps.
>>
>> On Sun, Nov 8, 2020 at 1:46 AM Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> wrote:
>>
>>>
>>>
>>>
>>> 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
>>> 

Re: [Tagging] Mapping terraced, irrigated farmland (e.g. rice paddies)?

[Joseph Eisenberg]

These are much taller than a step. There are earth banks at the edge of
each terrace, to keep the water in.

Here are some examples:

https://commons.wikimedia.org/wiki/File:Rice_terraces_on_Bali_-_Tegalalang_Rice_Terrace_-_Indonesia_06.jpg

https://commons.wikimedia.org/wiki/File:Fukuoka-Tsuzura_Rice_Terrace_in_an_Early_Summer-xl.jpg

There are also flood irrigated rice fields ("paddies") in flatter areas,
where there are just small earth berms between each field section. Usually
there is a slight difference in height, which varies based on the slope.
This can be hard to see from a distance:

https://pixabay.com/it/photos/uomo-riso-paddy-lavoro-panorama-5524518/

-- Joseph Eisenberg

On Sun, Nov 8, 2020 at 2:26 PM Graeme Fitzpatrick 
wrote:

> A while back, we had a discussion / proposal about mapping steps as an
> area, so that each step was mapped.
>
> Would that concept work here?
>
> Thanks
>
> Graeme
>
>
>
> ___
> 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?

[Joseph Eisenberg]

https://www.freemap.sk/?map=14/48.930467/19.094570=X

This is a nice topographical map, but it isn't serving client-side vector
tiles.

The tiles are jpegs, you can see jpg compression artifacts when zooming in.

Perhaps vector tiles are used on the server side, I haven't looked into all
of the code.

-- Joseph Eisenberg

On Sat, Nov 7, 2020 at 8:36 PM Martin Machyna  wrote:

> 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 

Re: [Tagging] Mapping terraced, irrigated farmland (e.g. rice paddies)?

[Graeme Fitzpatrick]

A while back, we had a discussion / proposal about mapping steps as an
area, so that each step was mapped.

Would that concept work here?

Thanks

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

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

[stevea]

Oops, "dearth" of data, not "death."


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

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

[stevea]

On Nov 8, 2020, at 7:58 AM, Anders Torger  wrote:
> I believe the processes available are limited in terms of fixing structural 
> problems.

You say you have long experience in open projects, that is a fantastic 
launchpad from which to join OSM and improve it, even criticize it.  I read 
that you (here, now) begin to identify what some of these "structural problems" 
actually are, but your major criticism seems to be that "processes available 
are limited" (I disagree), while my response has been that I agree with you 
that improvements in OSM take a (relatively) long time to fix.  Being 
consensus-based, OSM makes no apologies that major structural improvements take 
a (relatively) long time to fix, but major improvements usually DO take a long 
time to fix, regardless of organizational structure.  To wit, even if OSM were 
run by a single autocratic despot, major structural improvements would still 
take a relatively long time to fix.  This means "the processes available" being 
limited as specious (plausible, but wrong), as there is vast creativity on tap 
that OSM applies to solving problems:  this is another example of the power of 
crowdsourcing being unleashed performing powerfully.  Crowdsourcing doesn't 
apply simply to a bit of mapping here, a bit of mapping there adding up 
(though, that is true), it also applies to processes, code improvements / bug 
fixes, structural betterment, better wiki documentation, better tools and (over 
time), the voting in of better qualified board memberships which contribute 
sharper and better-applied skills to problems that need solving and 
improvements that need doing.  Sometimes there is "a step backward with two 
steps forward," but that is true in any organization.

OSM doesn't claim to be perfect, fast or complete.  It does get better, though 
slowly, that seems to be "baked in" to how OSM works.  It appears this may be 
too slowly for you, but I submit that this may not be true, should you apply 
some shoulder to the effort in appropriate places (improve the map, improve 
tools that provide you with your renderings...) rather than to complain.  
Especially as I (and others) might identify your complaints as 
misunderstandings that can be solved by working more within the established 
paradigms of OSM.  However, identifying problems is the first step in solving 
them, so I hear you, though mostly what I hear is frustration.  If you can 
propose better paradigms for OSM, you do have people listening.  (Though, this 
does not seem the proper venue to do so, we are likely putting people to sleep 
here).

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

Yes.  So?  Structural change in OSM isn't "a rough ride," it is hard work and 
takes time.  That's a truth in any organization.

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

Propose specific changes, please.

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

If your community is "less strong," then please strengthen it.  That's why it 
hasn't worked and it has (a rather obvious) solution, defined right here.  You 
seem quite technical and 

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

[Tomas Straupis]

2020-11-08, sk, 19:54 Joseph Eisenberg rašė:
> The reason is that at mid zoom levels there is far too much data
> in the database for it all to be made available in a vector tile
> format so that the map is fully customizable.

  Unless we will do a real generalisation which would mean we will
start doing cartography! Which is where all this thread started ;-)

  As for open source software stack. The only feature which is missing
is to cache layers separately (where "layer" is buildings, water,
landuse, places, could be two different versions of say landuse etc.)
and then combine them dynamically to final vector tile pbf on the fly
depending on the request. With postgis introducing vector tile
generation on the database side I think we will not have to wait long
for a lot of vector tile servers to pop-up.
  Client side: mapbox has done almost nothing with regards to
cartography in the last two years (and is still lacking support for
non abstract patterns, so things like wetlands look like crap), but
harpgl is gaining and you can always use openlayers which would be not
as sexy (fast), but for example you would have high quality text
(compared to webgl text).

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

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

[Richard Fairhurst]

Joseph Eisenberg wrote:
> you are not going to get a custom rendering from one set of vector tiles.

Sure you are.

You're not going to get every possible custom rendering from a single set of 
performant vector tiles, granted, but half of Mapbox's entire business model is 
custom rendering from one set of vector tiles.

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

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

[Joseph Eisenberg]

Re: "Vector tiles could allow for instant client-side switching of map
styles, the ability to customize the base layer, and allow users to make
custom maps themselves"

This is often claimed as a benefit of client-side vector tiles, but in
practice it is not possible.

The reason is that at mid zoom levels there is far too much data in the
database for it all to be made available in a vector tile format so that
the map is fully customizable.

If we were to include all features on the vector tile data, the rendering
would be too slow or would crash for many users, especially those who have
mobile phones, or lower-powered tablets, or even current low-end laptops.

Practical client-side vector tiles have to significantly simplify the data
and remove a number of nodes and features to make the rendering practical.
While some customization is possible (like hiding some icons and labels, or
changing the script or language of the text labels), you are not going to
get a custom rendering from one set of vector tiles.

User pnorman and several others had been working on a demonstration which
re-implements the current OpenStreetMap Carto style in server-side vector
tiles (the first step), but it is quite difficult to achieve a good result
with currently available open source tools, and there will have to be some
compromises which worsen the cartography in some cases.

I have not heard an update on this project in the past few months, so it
may be stalled.

-- Joseph Eisenberg

On Sun, Nov 8, 2020 at 8:48 AM Seth Deegan  wrote:

> 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.
>
>
> What they mean is that the current map styles run by other providers will
> not be necessary if we switch to vector tiles.
>
> Vector tiles could allow for instant client-side switching of map styles,
> the ability to customize the base layer, and allow users to make custom
> maps themselves (this is extremely powerful).
>
> This is pretty self explanatory, but I wanted to note earlier that vector
> tiles allow for the clickability/interactivity of every element on the map.
> Most new users who come to osm.org don't even know what the Query Tool
> does or that it exists. It's also pretty inconvenient and slow.
> Making everything clickable allows features to be explored with a possible
> beautiful UI like Google Maps.
>
> On Sun, Nov 8, 2020 at 1:46 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>
>>
>> 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 

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

[Martin Koppenhoefer]

sent from a phone

> On 8. Nov 2020, at 12:23, Allroads  wrote:
> 
> 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.


generally we use „place“ for toponyms (and named other things that can be seen 
as toponyms).

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

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

[Seth Deegan]

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.


What they mean is that the current map styles run by other providers will
not be necessary if we switch to vector tiles.

Vector tiles could allow for instant client-side switching of map styles,
the ability to customize the base layer, and allow users to make custom
maps themselves (this is extremely powerful).

This is pretty self explanatory, but I wanted to note earlier that vector
tiles allow for the clickability/interactivity of every element on the map.
Most new users who come to osm.org don't even know what the Query Tool does
or that it exists. It's also pretty inconvenient and slow.
Making everything clickable allows features to be explored with a possible
beautiful UI like Google Maps.

On Sun, Nov 8, 2020 at 1:46 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> 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 
> escribió:
> > 

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

[Anders Torger]

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?

[Anders Torger]

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?

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

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

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

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

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

[Anders Torger]

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?

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

[Anders Torger]

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?

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

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

[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] Mapping terraced, irrigated farmland (e.g. rice paddies)?

[Joseph Eisenberg]

In Indonesia, the rice paddy terraces are separated by earth or clay
embankments, usually about 1 meter to 2 meters high, made with local soil.

I wouldn't call those "retaining walls", since they are not made out of
stone, brick or concrete.

- Joseph

On Sat, Nov 7, 2020 at 10:46 PM Cascafico Giovanni 
wrote:

> Hi Joseph,
>
> retaining wall [1] is applicable to whatever area
>
>
> Il dom 8 nov 2020, 06:50 Joseph Eisenberg  ha
> scritto:
>
>> Is there a specific tag or method for mapping terraced farmland?
>>
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dretaining_wall
>
>> ___
> 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] Mapping terraced, irrigated farmland (e.g. rice paddies)?

[Martin Koppenhoefer]

sent from a phone

> On 8. Nov 2020, at 07:46, Cascafico Giovanni  wrote:
> 
> retaining wall [1] is applicable to whatever area


retaining wall is only applicable to linear features, and while it could be 
used here, it would make both, reading the map (looking for terraced fields) 
and mapping, more complicated than necessary (it would mean using 2 objects for 
every field, which have to be brought into relation).
IMHO for a terraced field a specific tag would make sense 

Is maybe “embankment” applicable?


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

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

[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