Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-21 Thread Tomas Straupis
2020-12-21, pr, 17:47 Brian M. Sperlongano rašė:
> The current data model works just fine for fuzzy areas: it requires a polygon
> combined with tagging that indicates that the area is "fuzzy".  Since the 
> current
> data model allows both polygons and tags, fuzzy areas could be mapped just
> fine from a technical standpoint.

  The question is not about their attributes (tags), but rather their geometry.
  All objects currently held in OSM are of large scale.
  Fuzzy areas are by definition objects of a much smaller scale.
  Having objects of different scale in the same layer (in the same
database in OSM case) is not good (causes a lot of problems) from GIS
perspective.

  So it is not good even if we do not add metaphysical properties like
"verifiability".

P.S. Third attempt: separate database? Or internal/technical separator
field and filter on API level? With possibility to switch between the
two in JOSM (and no possibility to edit both at the same time or reuse
parts)? wink wink :-D

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


Re: [Tagging] natural=fell not rendered, alternatives?

2020-12-21 Thread Tomas Straupis
2020-12-21, pr, 16:52 Anders Torger rašė:
> But what to do if the things you want doesn't
> really fit into what OSM currently is and strives to be...

  We are ALL OSM community. If somebody tells you that "I am OSM and
only A is right" - do not believe them.
  YOU define what OSM is and where it is going to by DOING.
  The more I look at it, the more it seems that fragmentation is
inevitable. Question is how much will remain "common".

"Don't let the bastards grind you down" - U2 :-)

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


Re: [Tagging] natural=fell not rendered, alternatives?

2020-12-21 Thread Tomas Straupis
2020-12-21, pr, 15:54 Anders Torger rašė:
> A local renderer would be limited in use <...>

  Not necessarily ;-)
  1. It could be a practical/visual proof of a "better way".
  2. It could be a testing ground for finding solutions to some
international (wider than OSM, say ICA) cartographic problems.
  3. If enough local communities create cartographic data schemas,
they could technically align them (tagging-cartographic maillist?) and
then data consumers would have to adopt to that as well.
  4. I'm not aware of the outdoors map specifics in Sweden, but at
least here OSM maps update much faster and also include
specific/thematic information for tourism, cayaking, craftbeer,
history and all other good things which official sources do not have.
And having all of that in one database (rather than an overlay) has
some important benefits.

-- 
Tomas

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


Re: [Tagging] natural=fell not rendered, alternatives?

2020-12-21 Thread Tomas Straupis
2020-12-21, pr, 14:42 Anders Torger rašė:
> I personally want to see that the community work for a more defined
> mapping baseline with OSM-Carto as a strong reference, used as a
> motivational tool for crowd-sourcing, and as it is with the current
> provider landscape -- also work as an end product. It does in parts
> already, and I want to see more of that. I also got a sense of urgency,
> map density in OSM has improved a lot, data sources that a mapper has
> access too has also improved a lot since OSM started, so mappers can
> today map much more than they could before and are more motivated to do
> so, at least in some places in the world. I want the OSM technical
> platform to be ready for that.

  In OSM for natural reasons cartographers are a small minority
comparing to majority of coders. Therefore cartographic goals do not
get through a "coder filter" (it is more important for majority to
have clean code than to have clean map).
  You might try, but in my experience the only way is to:
  * have a more cartographic agreement with local community (it is
easier in small scale, as you can meet in person, show good examples
and thus prove the value of cartography)
  * have your own country renderer (you can start with VPS for ~100EUR
a year and go up as your usage grows).
  * have your own country editor with your regional tagging schema (I
will publish instructions on how to do that in a month or two)
  * do most of the work yourself (or with a small group of cartography
oriented people) at least initially as resistance will be there anyway
until you prove/show results
  You will have cartographic maps and will not have to waste time
agreeing on cartographic nuances with people who do not understand
cartography. You will simply agree about them LOCALLY and use them
(OSM has a rule of "free tagging").

P.S. Frederik is right about fuzzy features, even in cartographic
perspective they do not belong in the same bucket as current OSM
features. I think you should have a separate database for those. It is
not hard to implement that as amount of data/changes is much lower.
They later end up in the same database in similar GIS tables as main
OSM data therefore are seamless to use in final products.

-- 
Tomas

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


Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-21 Thread Tomas Straupis
2020-12-21, pr, 11:02 Volker Schmidt rašė:
> Mass deprecations are counter-productive in general and independently of 
> whether they the new tagging is better in some way..

  +1

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


Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-20 Thread Tomas Straupis
2020-12-21, pr, 01:10 Clifford Snow rašė:
> Please refrain from calling out others as outlined in the Etiquette 
> Guidelines [1]

  Can you be more specific?

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


Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-20 Thread Tomas Straupis
2020-12-20, sk, 17:59 Paul Allen rašė:
> Too late, at least for iD.  Its authors have already decided to deprecate
> landuse=reservoir.  All this proposal does is document the fact.

  Strange sequence/logic tho:
  1. iD brakes the rules, does something contrary to what
OpenStreetMap/mappers do,
  2. instead of fixing the offender - iD, Brian decides to bend the
rules... ignoring the cartographic advantages of landuse=reservoir and
impossibility to achieve "full rule of natural=water" in any near
future as there are a lot of other tags to be massacred, not only
landuse=reservoir. waterway=riverbank - 255K water=riverbank - 1K <-
this even with iD once again lying about it being deprecated...

  I hope this proposal will be ignored as the initial one ten years
ago was. 20-30 people voting is nothing when we talk about tag with
almost 400K and much longer usage.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-17 Thread Tomas Straupis
2020-12-17, kt, 18:20 Joseph Eisenberg  rašė:
> That's not accurate, Tomas.

  Why? Mateusz without the end of discussion started, well continued
editing the wiki (I had to correct some of his misinterpretations
which have been discussed here), he also made some attempts in JOSM
trac, these are the things I follow, but I do now follow Mateusz
personally, so gods know where else he is buldozzing.

  This is only pushing towards the splitting of tagging standards even
further. We will introduce our approved tagging schemas/tools in
Lithuania, somebody will follow (some probably have already done so)
and what will we have then? I guess a wonderland for global data
consumers. We probably need per country tagging lists ;-)

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


Re: [Tagging] Rapids (whitewater) on rivers

2020-12-17 Thread Tomas Straupis
2020-12-17, kt, 00:02 ael via Tagging rašė:
> This is slightly off-topic in that I am picking up on the
> hazard tag rather than rapids. I see no objection to adding hazard=rapids
> although that might be redundant unless there exist rapids that are
> not hazardous. I suppose shallow rapids might qualify.

  Note that rapid does not necessarily have to be interpreted as
hazard. If prominent on the ground it can be one of orienting points
(with bridges, settlements, intakes etc.) - to cover distance
covered/remaining. We have a lot of "small rapids" which can be easily
passed with no risk even with babies and they're still marked for
orienting purposes.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
And while we're discussing here, Mateusz is already on a rampage to
change wiki pages, write patches etc. Thus buldozzing his opinion,
ignoring others. Showing "community building" behaviour.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 20:30 Kevin Kenny rašė:
>>   https://upes.openmap.lt/#17/56.296411/22.330154
> Looks good, I think... but what is the tagging?

  waterway=rapid
  At the time of usage it was deprecated (and plural), but I know what
that means and after each discussion on tagging list I'm less and less
inclined to propose/discuss anything here and evenmore editing the
wiki.

  My take is that cayaking info is added to be used for specific
purposes (well, cayaking) by specific people (cayaking enthusiasts,
cayaking service providers and tourists) so we know the practical
usage, we know cartographic requirements for data, look for suitable
tags in other places and use them, if there are none or they do not
fit the purpose - we add required tags. Important thing is that we can
distinguish each feature and if some more suitable tagging schema
emerges - we can always re-tag everything in a minute (and change
software in a day).

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 20:03 Kevin Kenny  rašė:
> Many smaller reservoirs have artificially hardened shorelines completely
> surrounding them, which could be why you thought that the symbology
> distinguishes 'lake' from 'reservoir.'

  This might be correct. I guess it depends on direction you look at
it: what is exception from the reservoir rule - hard shoreline or non
hard. I was thinking of the ways to map fuzzy shore in OSM and had the
same idea to tag fuzzy shoreline as a line - this would be the same
way as in your example but would need to de-emphasize rather than
emphasize the shoreline. And I'm sure I've seen a legend with blackish
border for reservoir, but do not remember if that was USGS or NATO map
(reservoirs have some distinct properties worth depicting on some
specific maps)... And I remember talking about lake/reservoir black
border symbolisation with one of the leading cartography experts in
Lithuania.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 19:44 Kevin Kenny rašė:
> With respect to water, another concern  of mine is that our tagging schema 
> does not
> offer any way to tag that there are rapids in a river without knowing how to 
> grade the
> difficulty of a canoe or kayak run.

  Why? Cayaking info is pretty rare - opposite of lake/reservoir data.
Therefore it's fine to map what you need only:
  https://upes.openmap.lt/#17/56.296411/22.330154

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 18:58 Ture Pålsson via Tagging rašė:
> Could you elaborate a bit on what cartographic features on that map are
> possible or impossible with the different reservoir tagging schemes?

  Symbolisation (colour), selection (different classes for different scales).
  In other maps reservoirs (US?) could have black border.
  GIS analysis is another beast where these classes are important as different.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė:
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)

  BTW. It is another advantage of landuse=reservoir schema. It forces
people creating map to understand that there ARE different classes of
water. Then they have to understand what those classes are (and why)
and choose which are appropriate in their particular products. If you
have an umbrella tag like natural=water most will simply go with such
simple where condition and therefore miss some very important things
(and create low quality maps, and will not learn important lessons).

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė:
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)
> https://www.openstreetmap.org/#map=14/54.3643/18.7150
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=C
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=T
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=H

  Why is there no label for waterway polygon?
  What about maps made according to Cartographic conventions?
  You know, something on the lines of: https://map.geo.admin.ch Would
it be possible to make maps of such quality writing general queries
like natural=water?

  A lot of Cartographic papers are open. Look at those mentioning VGI
or OSM directly and check what cartographers very diplomatically say
about OSM maps/cartography (not data). Why is that? Could it be that
there is simply too much resistance to push something more advanced
into OSM?

>> Best system is to use codes, not names for keys/values, but that is a
>> totally different "saga".
> Feel free to propose this one.

  From my perspective there is a big problem with making complex
changes/decisions (requiring a lot of specific/thematic
knowledge/experience) as there is no way to value "votes" of people
with different experience differently. If it is not valued differently
then the result you get is an average. What is an average of 1, 1, 1,
2, 2, 50? Why would 50 want to be involved in something where result
will be 10 and you would have to fight for each action?

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 17:19 Brian M. Sperlongano rašė:
> The statistics reflect all areas, regardless of which editors were used to 
> create them.
>  I stand by them, as numbers do not lie.

  Have you heard of the saying "correlation is not causation"?
  You have to understand where numbers come from and why in order to use them.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
> I agree that it is useful only for primitive rendering of water areas
> (that possibly filters water areas by area but does not distinguish
> between lakes and rivers). It may be worth mentioning.
>
> But it is also the most typical and common way of rendering things.

  How do you decide that it is most typical and common way of rendering things?
  ALL maps I created or seen in GIS/Cartography world, be it online or
printed, interpret water classes differently, especially
basins/riverbanks... And it will be even more important moving to
vector tiles.

> This is a double edged sword, it also means that mapper unsure
> whatever something is natural or man made (common in case
> of mapping based on aerial images, sometimes even in
> case of survey) is unable to mark a water area.

  But that is a point, mapper should find out if we want to have
higher quality data. There is usually some source available you can
use. You can always add fixme, if you're unsure.
  And for the case of pond it IS possible to distinguish it from
reservoir/lake straight away.

> And distinguishing natural vs man made is still possible
> with water tag anyway.

  99% water objects mapped with iD I've seen are water=pond...

> (similarly like I have not mentioned that both natural
> and landuse are quite counterintuitive key names here)

 Best system is to use codes, not names for keys/values, but that is a
totally different "saga".

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
Brian, you're using statistics which DO NOT represent mappers preferences.
If you would use only JOSM created objects - then it would be close to
mappers preferences (as JOSM allows mappers to choose).
But you use iD created/adjusted objects and as it does not allow
showing your preference (drilling down into tags is only a theoretical
possibility) and even pushes you to overwrite other peoples
preferences you have to exclude iD tainted objects if you're trying to
get "community preference" from statistics.

Therefore I would suggest starting with the core - arguments
advantages/disadvantages of both schemas.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
> (just added)

  Thank you. Maybe it is better to discuss here before adding to wiki?
  My arguments on the points you've added:

  1. Regarding benefit of having a combining level/tag natural=water.
If today you would query all data with natural=water - you will get
not only lakes and reservoirs grouped, but also riverbank polygons
(totally different beast) and micro elements like water=pond. This
could only be partly useful in the largest scale maps and only if you
make very simple maps and for some reason use the same symbolisation
for such different water classes. For example ponds usually have less
complex and less prominent symbolisation because of their size and
importance. Riverbanks would not need polygon labelling, but rather
use river (central) line for label placement. Most of GIS/Cartography
work goes in middle/small scales and it will be impossible to use only
natural=water there, you would have to add "and water not in
('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
makes it of the same complexity from coding perspective as original
water scheme.

  2. Very important disadvantage of water=reservoir from
cartographic/gis perspective: it allows mappers to NOT differentiate
between natural lakes and man made reservoirs. If first point
describes how different classes are USED, this second point is about
how these classes are CAPTURED.

  Did I miss anything?

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
> I get that you consider benefits of natural=water water=* schema
> as unimportant

  Can you LIST the benefits? As you see them TODAY. So that we could
evaluate/compare?
  (Not point to proposal on wiki, as largest part of it never materialised)

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
> If you believe that your argument in favor of tagging reservoirs as landuse is
> strong, then you should have no objection to placing this question up for a
> community vote, and allowing the community the freedom to decide.

  Brian, landuse=reservoir is the ORIGINAL and ACTIVE schema. Why
should anybody propose the vote for it?

  I do not like voting on wiki because it is clearly a flawed process
(as discusses a number of times), what do 20 wiki participants/people
mean against the actual mappers? We could end up in the same situation
as with original water=reservoir proposal where somebody with barely
few months of participation in OSM and no knowledge of GIS/Carto
makes/influences the decision/proposal...

  And what is a problem of listing benefits of water=reservoir schema?
If there are none, then the only logical decision is to deprecate
water=reservoir, because it would make it worse of the two. Shouldn't
we get ARGUMENTS before we go to any kind of voting/decision?

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-16 Thread Tomas Straupis
2020-12-16, tr, 01:32 Brian M. Sperlongano rašė:
> The iD editor preset appears to use water=reservoir while the JOSM
> preset appears to use landuse=reservoir.

  Not entirely correct.
  * JOSM gives freedom to mappers and supports BOTH.
  * iD forces to use water=reservoir and evenmore pushes users to
change tagging by disguise of "upgrade" - therefore even mappers who
do not understand/know the difference are inclined to change the
tagging. <- this is the reason for current stats

  My understanding is that given landuse=reservoir is the original
water schema, the new one should show some benefits to replace the
original one? Or we do not care about consistency and simply go on
with replacing very prominent schemas for no good reason?

  My take is that:
  * landuse=reservoir is better compared to natural=water+water=x
because it pushes mappers to make distinction for these
GIS/Cartographically very different classes of water. Therefore if
landuse=reservoir is deprecated tagging will be worse.

  What are the benefits of water=reservoir?
  Given that full scope of proposal to put all water classes under
natural=water (the purpose which is disadvantageous from
GIS/Cartography perspective) have failed and we're now only talking
about two classes of water (natural and man made), and classes which
are very different and therefore should not be merged.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Tomas Straupis
2020-12-13, sk, 20:41 Mateusz Konieczny via Tagging rašė:
> Following outcome of approved proposal that you dislike
> is not indicator of not following
> standard IT processes of product development.

  Following some wiki page (which states that landuse=reservoir is not
deprecated) written by one person and voted by few rather than de
facto situation in other editors and database is huge problem with
analysis.
  In case of iD it is even worse - it shows coders of iD did not want
to give a tool, but rather to make influence which they continue to do
quite openly, especially with a tactic of "upgrade tags". Compare that
to JOSM - which is democratic, follows OSM principle of freedom and
lets us - mappers - choose.

  Both schemas are mostly identical in what classes of object can be mapped.
  1. water=reservoir benefit could have been on coding side: having
natural=water as an "umbrella" tag but it did not work out that way
(so I do not know what is a perceived advantage now?)
  2. landuse=reservoir benefit is GIS/Cartographic: we must indicate
if it is a natural or man made waterbody.
  Now you decide which is more important to openstreetMAP.

-- 
Tomas

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Tomas Straupis
2020-12-13, sk, 20:09 Mateusz Konieczny via Tagging rašė:
> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> Mateusz, can you point out which of my claims is a lie?
>
> "iD coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT)"

  Let's go back in time. It is 2012. iD developers are to add water
tagging schema to their newly baked editor. The candidates are IN
2012:
  1. landuse=reservoir - the only schema in activu use, widely used,
200K objects tagged, documentation written, tutorials written.
  2. water=reservoir - unused (5K? 10K?).
  iD developers decision: go with option 2. I do not see how such
decision could be counted as "IT-wise sound"?
  (my suspicion is that the reason was iD's tag layout being
tag+subtag and there water=reservoir was better suitable, but this is
just my speculation, if true that would be one more proof of lack of
IT experience)

> 
> "coders of iD decided to lie to the users that landuse=reservoir is
> deprecated which it never was"
>
> It is deprecated by 2011 proposal, see 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation

  Please read everything, not only the part you're interested. Zverik
agreed that it is NOT deprecated. And it was agreed in many many other
discussions that landuse=reservoir was NEVER deprecated.

> usage/requirements must lead technical decisions. That is IT BASICS.
>
> It was not an unused schema and it was proposed, approved and used before iD
> started using it and later aggressively promoting it.

  2012:
  landuse=reservoir - 200K,
  water=reservoir - 5K? 10K?

  Should we continue to argue in the dungeons of history without
thinking about the future?

  The problem is that it dragged for almost 10 years. Now ANY decision
will be bad. That is why decision is always postponed, but time will
not change anything. The hole is till there, there are no
rules/process to circumvent that. So the situation can repeat again.

-- 
Tomas

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Tomas Straupis
2020-12-13, sk, 18:58 Brian M. Sperlongano rašė:
> Let's please assume good faith and be respectful while we discuss
> differences of opinion with an open mind - we are all here for the
> same reason - working together to create the best possible map for the world.

  I do agree that sometimes I get carried away, sorry I will try to reduce that.

  At the same time I ask to actually discuss the reasons why this saga
happened and ways to reduce the possibility of such harmful
duplications happening again. Bulldozing one opinion and ignoring the
other is not a good solution.

-- 
Tomas

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Tomas Straupis
2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not what was better
>
> This is 100% untrue, and you insult people. Stop making such things.
>
> For start, iD authors (also ones that made decisions about tagging
> presets that I consider to be mistakes and going against consensus)
> had no problem with basics of IT and IT processes of product development.
>
> water=reservoir was launched (created) in 2011
> see https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details
> iD started in 2012 ( https://wiki.openstreetmap.org/wiki/ID )

  Mateusz, can you point out which of my claims is a lie?
  I didn't say iD invented duplicate schema, I said that schema was
lying dead until iD decided to introduce it as the only way to tag
water, introduction "launched" new water schema adding any
considerable usage (as it was the only option for iD mappers).

  Introducing duplicate and unused schema (especially as the only
option) is not a good IT decision, basic analysis should have shown
that. But in case of id it was technology leading functionality and
thus leading users when in IT it must be the other way round -
usage/requirements must lead technical decisions. That is IT BASICS.
Lack of such understanding is the reason why I claim iD developers
lacked basic IT knowledge.

> , and introduced
> water=reservoir as the only way to tag, all this at the time when
> water=reservoir usage was close to zero!
>
> See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology
>
> Usage in January 2019 was about 200 000 already.
>
> "water=reservoir usage was close to zero" is untrue

  Key word "introduced" so it is 2012, not 2019.
  water=reservoir usage in 2012 is close to zero.

> It is deprecated by 2011 proposal, see
> https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation

  The author of this proposal agreed that standard water schema is NOT
deprecated. And a few people voting in wiki cannot deprecate a tag.
Only people actually mapping can do that.

> BTW, you are AGAIN spreading false statements and claim that iD
> invented water=reservoir. Please stop doing this.

  Do not copy/paste my words in random order and you will not get such
claims from me :-)

  Anyways, there is no way I will be able to teach IT things people
who do not want to learn. Let's not rewrite the history of this saga
and lets move forward instead of repeating the same discussion again
and again. Let's do what is possible so that this does not happen
again:

  * When tagging schema CAN be changed and when it CAN NOT?
  * What ADVANTAGES are required to allow deprecating current schema?

-- 
Tomas

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Tomas Straupis
But prudent way would probably be to come with some rules on change of
tagging schema. Like:
* When tagging schema is too widespread to be protected against changes
* What benefits should new schema add in order to deprecate existing schema

Because otherwise this plague of deprecating existing widespread
schemas (water is not the only impacted area here) in order to bring
some dubious "benefits" will continue. Some people simply do not have
experience and do not understand what is the value of stability and
what are the actual costs of changing something which is already
widespread (for this I like to give an example of highway tag which is
was correct when it was created but is incorrect now, but we do not
change it for the same reason of stability and total cost).

P.S. Stability does not necessarily prohibit freedom of tagging.

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


Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

2020-12-13 Thread Tomas Straupis
2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
> 2019 was a turning point, and over the last two years, landuse=reservoir has
> been on a steady decline, while water=reservoir continued its rapid growth.

  New/duplicate schema with water=reservoir only launched because iD
coders decided to skip standard IT processes of product development
(or were not familiar with the basics of IT) and simply went for what
they personally liked, not what was better, and introduced
water=reservoir as the only way to tag, all this at the time when
water=reservoir usage was close to zero!

  And the only reason for change of stat starting 2019 is because
coders of iD decided to lie to the users that landuse=reservoir is
deprecated which it never was and started replacing landuse=reservoir
under their highly controversial disguise of "upgrade tags".

  So the change of statistics is not the preference of mappers but
preference of some nerds.

> Is it time to more directly recommend that mappers favor natural=water + 
> water=reservoir
> *instead of* rather than *in addition to* landuse=reservoir?

  I would propose to deprecate water=reservoir and even more - add
guards so that such pointless/nerdy duplicate standards would not be
introduced in the future.

  Note that one of the main nerdy points of this schema was to have a
possibility to write sql easier (somebody has problems with "and/or")
and this would also require riverbanks to fall into this new water
schema. And riverbank clearly does not fall into that even with iD
lying about it too. Therefore the only point has failed and this
stupidity is spreading havoc in tagging of such prominent water
features for more than 10 years now.

P.S. There is quite an easy solution to have a separate iD instance
for beginners with correct tagging presets loaded.

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

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-07 Thread Tomas Straupis
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 Tomas Straupis
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?

2020-11-07 Thread Tomas Straupis
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?

2020-11-07 Thread Tomas Straupis
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?

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

2020-07-21 Thread Tomas Straupis
2020-07-21, an, 15:17 Mateusz Konieczny via Tagging rašė:
> Because despite claims mentioned above - there are also people preferring the 
> second schema,
> it is not case of "iD developers vs community" like it is/was with some case.

  Situation when there are no barriers to changing widely used tags is
very dangerous.
  What would happen if somebody would see one of numerous discussions
about how highway tag is "incorrect" (as it could signify things which
are not highways) and propose a new schema with totally different
tags, and then iD goes out of fashion, somebody writes a new editor
ChakaLakaLekker, makes the "new" road/way schema the default/only one
available and in some time starts deprecating/removing highway tags.
Would that be OK? If not, why was it allowed with water?

P.S. Christophs thoughts are also right on spot, but it requires going
even further - to cartography.

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


Re: [Tagging] Riverbanks

2020-07-21 Thread Tomas Straupis
2020-07-21, an, 15:00 Mateusz Konieczny via Tagging rašė:
>> It is totally NERDY.
> What you mean by that?

  There are two very different things:
  * IT
  * coding

  IT considers wider/higher-level things like stability, quality of
the final product, documentation, usability etc. etc. IT expertise is
gained by years of doing work on IT (coding is NOT IT expertise).

  Only coders/nerds are interested in things like "making sql slightly
easier to write in some cases". Such motivation would be totally
insufficient for ANYBODY with at least a little bit of IT experience
to cause change of widely used thing (in this case water tagging
schema). Such change would be considered stupid by anybody with IT
experience. Only nerds care about where clauses having one line or two
lines without thinking about the wider picture: data consumers,
documentation, videos - stuff which is already produced, stuff which
in some cases cannot be changed (like printed books) or costs a lot to
be changed.

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


Re: [Tagging] Riverbanks

2020-07-21 Thread Tomas Straupis
2020-07-21, an 13:15, dktue rašė:

>
> So why can't the wiki state: "If you tag, then please do so using
> waterway=riverbank" (as this is preferred by the *community*)?
>

 There is no way to calculate the "opinnion" of the community and
authoritarian/dictator attitude of iD coders and lack of action ramped up
usage of nerdy schema close to original OSM one.

 And there is nobody bold to solve this, as there is no governing
body/expert group.

 Local communities can do it. In Lithuania nerdy scheme is prohibited in
favour of clean and consistent data.

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


Re: [Tagging] Riverbanks

2020-07-21 Thread Tomas Straupis
2020-07-21, an, 11:20 dktue rašė:
> Why do we need both variants and why don't we just say that
> waterway=riverbank is preferred?

  There is an original OpenStreetMap water schema with lakes as
natural=water, reservoirs as landuse=reservoir, riverbanks as
waterway=riverbank etc. It is a perfectly working schema.

  At some point there was a new schema proposed with a totally nerdy
motivation "to make some sql's simpler". That new schema has no
advantage in cartography, GIS or IT sense. It is totally NERDY. This
nerdy scheme was ignored in the beginning but then came the iD which
took a totally non-analytical and authoritarian attitude and not only
chose to support nerdy water schema, but even decided to support ONLY
it. And in recent year iD coders went even further and started lying
to its users that original OpenStreetMap water schema is "deprecated'
even when it never was.

  So this is the reason why we have two schemas. It is very
unfortunate that there is no way to prohibit such nonsense nerdy
schemas into OpenStreetMap :-(

-- 
Tomas

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


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-23 Thread Tomas Straupis
> Very well put! If I understand correctly, to do this without heavy 
> pre-processing,
> the information would have to be in the tags?
> Would it have to be in the tags of every individual way, or would a tag on
> an encompassing area (e.g. landuse=residential) be sufficient?

  Correct. Information would have to be on individual ways, because
say two identical parallel ways close to one another should have to be
reduced to one way.
  Even more: road network pruning is scale dependant, so additional
information could be multiplied by the number of scales required.
  Note: additional information on ways would have to be adjusted even
if the way itself does not change but information in surroundings
change. For example forest path can be placed on a map (in a middle
scale) but later removed after a parallel road is built alongside the
path (say 50m away from the path even without touching/influencing the
path itself).

  Therefore such tagging would go against OSM conventions.

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


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-22 Thread Tomas Straupis
2020-05-23, št, 04:51 Jarek Piórkowski rašė:
> See also: not rendering roads or hamlets in very sparsely populated
> areas because we have one map style which needs to accommodate central
> European densities.

  OSM-Carto is a very well done DATA VISUALISATION. It is not a
cartography. What you're asking cannot be done with only tagging as
you will have ways which look exactly the same but will have to be
removed in one place and will remain in the map in another place. What
you're asking is accomplished in CARTOGRAPHY by "road network
pruning". It checks density/class of roads and removes minor ones at
the places of high density. It is one of cartographic generalisation
functions. All important generalisation functions take additional
heavy pre-processing and that is probably a reason why OpenStreetMap
does not have any Cartography projects yet.

-- 
Tomas

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


Re: [Tagging] landuse meadow getting the right description emphases

2020-03-15 Thread Tomas Straupis
2020-03-15, sk, 08:53 Warin rašė:
> There is no real 'force' on a mapper to do anything. If a mapper chooses not 
> to use the subtags then they don't have to.

  landuse=meadow was mention together with natural=grassland etc. If
it is only about subtags meadow=* - I'm fine with that.

> Similar can be said of many sub tags. If mappers want to map it then give 
> them a way to do so in a logical manner.

  Sure. That is why I commented. Amalgamating landuse for map
rendering is not a trivial task.

-- 
Tomas

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


Re: [Tagging] landuse meadow getting the right description emphases

2020-03-15 Thread Tomas Straupis
Why would you want to "force" using more than one class for meadows
when absolute majority of maps will not need more that one class?

-- 
Tomas

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


Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

2020-01-28 Thread Tomas Straupis
2020-01-28, an, 20:15 Jmapb rašė:
> Thanks for the background. Looks like Richard Fairhurst already reverted the 
> "shared foot/bicycle must be path" assertion on the cycleway=* page. J

  Yet for ten years or even more the logic was that if the same way is
designated for both pedestrians and cyclists, it cannot be tagged with
highway=footway - as it is for cyclists as well, it cannot be tagged
with highway=cycleway because it is for pedestrians as well, so such
shared ways for this long period were tagged as
highway=path+bicycle=designated+foot=designated. This has also been
the preset in the main OSM editor - JOSM. This is in documentation and
maps for ten or more years.

  Are there any reasons why this must change now? Any benefits?

-- 
Tomas

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


Re: [Tagging] Strange tags

2019-09-30 Thread Tomas Straupis
2019-09-30, pr, 10:35 Martin Koppenhoefer rašė:
>> topo map, or ask virtually any local 'what mountain is that big one?'
>> while pointing, and you'll get an answer, but for many of these peaks
>> I don't think I've ever seen a sign with the name, so I've been told
>> that in such a case the name is not verifiable!)
>
> IMHO this would represent just a small minority of people thinking so.
> Generally verifiability would be satisfied if you could go in the area
> and ask the people, there is no requirement for a sign.

  If there is an official open freely accessible dataset, you (and
anybody else) can use it to verify.

-- 
Tomas

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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
Well, I would be reluctant to tag the ways leading to this remote
house as unclassified or residential:
https://openmap.lt/#h/17.01/54.19809/24.27953/0/0/
These are public ways/roads, anybody can use them - they are not
private. Yet they are not in the database of Lithuanian road agency,
so they are not managed by road agency.

Here in Lithuania we have a rule for at least ten years that: if you
can see tracks, then it is a track :-) And it corresponds very well to
what we see in topographical maps.

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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
2019-08-04, sk, 12:59 Florian Lohoff rašė:
> If B is a public road A cant be private property and thus not be
> a service. If B is a track A can be a service because both
> of them share the concept of not beeing for the general public.
>
> Or vice versa. If you make A a service B cant be a public road.

  And therefore *track is higher* in the hierarchy than service. Right?

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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
All right, let's make it more detailed and more extended.

R
R
RAAA
R  A
R
R
R
R

Now A and C are ways leading into the inner territory of residential
building(s). But A has another important road B getting out of it, and
C does not. Which means A has through traffic while C does not. But
all of them are very minor ways visible as two tracks on the ground.
Way C is used say twice in a week.

Now I would like to skip road C at small scale, but leave A, because I
want to leave B.

Can we agree on some scheme to tag this (do data augmentation), so
that less people doing cartography stuff have to resort to heavy
generalisation operation such as road pruning?

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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
Let's say we have a residential road R. Going out of this residential road
there is a way A into the neighbouring residential area (say 50m length).
Out of that way A there is anower way B leading into the fields/forest
which lies outside of the residential area. B way is long enough and
significant, say leading to some locally significant object (ruins, tree,
lake).

R
R
RAAA
R  A
R


What could be correct:
a) A - service (service=???), B - track (tracktype=???)
b) A - track grade1 B - track grade>1
c) others
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
2019-08-04, sk, 11:56 Erkin Alp Güney rašė:
> Paved: service unpaved:track

  service could always be paved and unpaved.
  track used to be always unpaved, but somewhere somehow tracktype1
became paved :-)

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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
2019-08-04, sk, 11:32 Florian Lohoff rašė:
> For me unclassified is the same as residential. <...>

  Ok, so unclassified vs residential is regionally defined, as I wrote.

  But what about service/track?

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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
> Personally, I'd have put residential / living together above unclassified

  Interesting. Unclassified was always (more than 10 years) defined
for "through traffic" which puts it a higher in a hierarchy. From what
I understand it was always in the group of primary/secondary/tertiary
just the one which does not have an official classification - thus
"unclassified".

> Once again, personally service before track, maybe further split that 
> highway=service by itself is higher that the "types" of service road 
> (driveway, parking aisle etc)

  This way of interpreting service would make it impossible to
identify if missing service=* tag means:
  1. missing tag/information
  2. specified higher priority service road
  For example if you have service=driveway and want to make it higher
priority service road, you should change service value to something
else rather than remove service=* key.

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


[Tagging] Road hierarchy

2019-08-04 Thread Tomas Straupis
Hello

  Road hierarchy is needed for a number of things:
  * deciding which classes of roads to display on different scales in a map
  * performing road network validation
  * other tasks (f.e. typification of buildings - orientation)

  Hierarchy would be different in different context: motorcar, bicycle,
pedestrian etc. For the time being I'm only asking about motorcars.

  There is non written (or I could not find in wiki) or "de facto"
hierarchy:
  * motorway
  * trunk
  * primary
  * secondary
  * tertiary
  * unclassified
  * residential
  * living_street
  In some regions unclassified has a higher position in hierarchy, in other
regions unclassified, residential and living_street have the same position.
This is fine for the time being.
  I'm also intentionally skipping _link classes.

  My question is about what goes further:
  track / service
  Which of them is higher?
  Does additional tags influence this? For example does adding
service=driveway reduce position in hierarchy of service road? Does any
value of tracktype change position of track road?

  And in general, is there a point of agreeing on this globally or it will
stay regional anyway?

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


Re: [Tagging] JOSM's "suspicious" path data warnings

2019-07-08 Thread Tomas Straupis
2019-07-08, pr, 10:53 Márton Keleti rašė:
> I consider using highway=path on urban shared cycle/footways a very bad an
> confusing practice. <...>

  Idea is that path is not only "one man width unpaved" way, but it is
also a way where neither footway, nor cycleway fits because the way is
for both.
  This is how it was for many many years (at least 10 years?). It is
already used in many many places. It does the job perfectly.

-- 
Tomas

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


Re: [Tagging] track smoothness/quality

2019-07-02 Thread Tomas Straupis
2019-07-03, tr, 08:04 Mateusz Konieczny rašė:
> 2) Take the leading sentence mentioning Solid/Soft out of the tracktype 
> description (or de-emphasize it)
> I am dubious about redefining extremely
> popular tags. <...>

  How come? You are pushing the changing of entire water tagging schema!

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


Re: [Tagging] landuse=reservoir vs water=reservoir

2019-06-11 Thread Tomas Straupis
> I find very strange that reservoir is a landuse by itself
> it would be a bit like putting landuse=rest on a bench
> or landuse=stop on a parking lot.
> <...>

  There are a infinite number of arguments on both sides. Pandora box
was already opened and dual standard for water tagging already exists.
  The fact is that landuse=reservoir was and is used on most
reservoirs so it cannot be flagged as "worse".

  The question is about treatment of these two tags in the wiki.

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


[Tagging] landuse=reservoir vs water=reservoir

2019-06-11 Thread Tomas Straupis
Hello

  landuse=reservoir is from original OpenStreetMap water tagging scheme.
  water=reservoir is the newer one ("all blue is natural=water") with
no advantages over previous one. Original (landuse=reservoir) is still
more prominent even with Mapbox/iD's aggressive push for the later
one.

  Now OSM wiki for some reason has a note on landuse=reservoir that
"better alternatives exist". Which in my opinion has no base. In my
opinion both reservoir pages must have similar treatment:
  1. no "better" (especially if newer and less popular is interpreted
as "better")
  2. "alternative" should be mention on both or none of the pages.

  What do you think?

-- 
Tomas

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


Re: [Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-17 Thread Tomas Straupis
And here the idea of a new separate data layer (as in GIS) for geometries
of fuzzy features rises again... 
Waiting for its time.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Large areas of landuse=grass in the Netherlands

2019-03-11 Thread Tomas Straupis
  Some time ago I was proposing to introduce topology rules, at least
locally. Those (besides a lot of other stuff) would cover which
polygons can be above which polygons, which polygons can not be above
which polygons etc. Such rules are already used for years in Lithuania
in regards of forests.

  F.e. landuse=forest can not intersect/cover
landuse=residential|industrial|commercial|reservoir, natural=water,
waterway=riverbank. But for small patches of trees we use
natural=wood, which can ONLY be above (be covered by)
landuse=residential|commercial|industrial.

  Idea is that for large scale maps you use all of these polygons
(with natural=wood on top) and for small scale maps you simply ignore
natural=wood.
  This simplifies cartographic tasks a lot. It is also capable of
separating micromapping without the need for complex generalisation
calculations.

  As far as I understand, landcover tags are supposed to be used for
exactly the same tasks (as natural=wood in my example). This means
that all natural=wood polygons in Lithuania (not too much - 1500)
could be replaced with landcover=wood|forest|trees (whatever) if that
was rendered in OSM-Carto, as some people in Lithuania still use
OSM-Carto data visualisation and not the local OSM maps.

  If I understand correctly, landuse=grass is the same thing for
grass: landuse=grass is a micromapping (for large scale maps only),
landuse=meadow is for smaller scale (actual landuse) mapping. So you
could have the same topology rules in Netherlands to check
automatically that all landuse=grass is above some actual landuse
(hence the need for landcover to be able to have both). This way there
would be an automated way to check quality of OSM data.

  IMPORTANT: There is no way to ensure the quality of OSM data without
automated checks doing MOST of the work.

-- 
Tomas

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Tomas Straupis
2019-02-20, tr, 20:08 Florian Lohoff rašė:
> From the original meaning unclassified was the lowest class road in
> rural or off city limits. residential was the lowest class road within
> city limits. (Assuming that city limits mean residential usage)

  unclassified "original" meaning was "for through traffic". Which is
"better", or in normal terminology - "higher in the road network
hierarchy".
  As for the name "unclassified". Both residential and unclassified
are roads which do not have national reference numbers/classification.

  If unclassified and residential would be identical, what would be
the reason to tag such roads differently?

P.S. Name "residential" is kind of misleading. Because of the lack of
highway type for large arteries in industrial/commercial zones,
residential is used for that in order not to have just "service"
roads, and not to tag them "unclassified" as they are not for
through/important/high traffic.

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Tomas Straupis
I would agree with those stating importance of road network hierarchy and
connectivity (for both routing and cartography).
Having unclassified as higher than residential but lower than tertiary
helps a lot.

Maybe google will translate this old post with some practical examples and
some technical connectivity checking info:

https://blog.openmap.lt/2017/12/09/keliu-hierarchija/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tree rows vs individual trees

2019-02-11 Thread Tomas Straupis
2019-02-11, pr, 16:26 Ture Pålsson rašė:
> That possiblity already exists, as tree_lined=*. However, I believe tree
> rows sometimes appear on their own. For example, the tree row in this
> picture (which was in the side bar of the Wiki for natural=tree_row)
> looks like it is not lining anything in particular:

  But this is OSM wiki. What about "traditional" cartography? I
couldn't find "separate" tree row in topographic maps (last 150 years)
of Lithuania, but this could be because such feature is not popular on
the ground here.
  On the other hand, tree rows alongside roads/railroads/canals could
be mapped with attribute and separate ones with natural=tree_row
object.
  Individual trees would be very hard to use for such purpose - so
useless anyway.

> Byt yes, using tree_lined=* when appropriate certainly makes my life as
> a renderer developer easier, though I guess it is harder to combine with
> also mapping individual trees. :)

  You will probably skip trees on 25k or 50k? :-)

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


Re: [Tagging] tree rows vs individual trees

2019-02-11 Thread Tomas Straupis
2019-02-11, pr, 11:29 Ture Pålsson rašė:
> As someone who tries to render smallish-scale (typcally 1:25000 or
> 1:5) maps from OSM data, I am always slightly annoyed when someone
> states that something does not need to be mapped bacuse it can be
> inferred algorithmically from other data, without describing or at least
> giving a reference to such an algorithm.
>
> Tree rows -- real tree rows, i.e. a row of trees planted on purpose to
> function as a landscaping feature, not just some random trees which
> happen to be in a line -- are important landmarks and often show on maps
> as rows of green dots. However, the individual trees are typically too
> close to be shown at their real positions, so some generalization is
> required. Tagging the tree row provides such a generalization. I have no
> doubt that it is theoretically possible to synthesize tree-row objects
> from mapped trees, but I would guess that doing so with an acceptable
> number of false positives and negatives is close to a masters-thesis
> project.

  Exactly!

  Two things to add:
  1. At least in Lithuania cartographic (topographic) "tree row" is
defined as "a row of trees groing alongside a road or railway". That
is random trees somewhere in a field do not become a "tree row" even
if they are in a row.
  2. If (1) is true in other countries, maybe "tree_row" should be an
attribute of a road/railroad? Say
highway=residential+tree_row=left|right|both. This way it would be
much more convenient to create cartographically correct maps in 25k
50k scales without resorting to complex generalisation operations like
displacement?

-- 
Tomas

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-10 Thread Tomas Straupis
2019-01-10, kt, 10:54 Dave Swarthout rašė:
> We just went through a whole discussion about mapping bays as
> polygons. (see 
> https://lists.openstreetmap.org/pipermail/tagging/2018-November/040911.html)
> <...>

  Yes, I agree with everything. You are describing why polygons are
needed for labels, you and Martin are describing why it is not
practical and what temporary workarounds could be used. Thus my
initial note: this is one of the things pushing in direction of
creating multiple data layers in OSM (some day in the future, say 2024
:-).

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-09 Thread Tomas Straupis
2019-01-10, kt, 09:06 Martin Koppenhoefer rašė:
> coding the geometry into the db does not necessarily mean creating polygons 
> though.
> You could also store just 3 nodes and a hint that these are representing a 
> polygon, to store a triangle (for example).

  Sorry, I did not get it. How saving only vertexes is better than
having a polygon (made out of those vertexes)?

  Full geometry is required to be able to calculate label positions on
all scales. For small scales this could be a simple curved line
(calculated from polygon geometry), for large scales it could be a lot
of labels placed/scattered on the same polygon geometry and
approximating (simplifying) such polygon too much would decrease
number of labels placed or labels would be placed outside of an object
which is even worse.

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-09 Thread Tomas Straupis
2019-01-09, tr, 19:36 Mateusz Konieczny rašė:
>> And here we're one more step closer to introducing gis layers in OSM.
>
> I have no idea how natural=peninsula tagging is related to that.

  In order to have correct labelling you need polygon geometry for
peninsulas (as well as for other objects), but having them in current
OSM database is not practical.

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-09 Thread Tomas Straupis
And here we're one more step closer to introducing gis layers in OSM. Not
there yet, but as maps created from OSM data start aproaching cartographic
conventions, the only other way is to use other - non OSM sources.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] My "weirdly unnatural aversion to relations"

2018-09-30 Thread Tomas Straupis
2018-09-30, sk, 17:09 Christoph Hormann rašė:
> Note this is a completely wrong characterization of the water=* tagging
> scheme that is playing on nationalistic sentiments.  You should not do
> that.

  Sorry, had no intention to insult anybody.
  This alternative scheme _originated from Russia_ when standard water
schema was already used all around in full toolchain - thus the name.

-- 
Tomas

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


Re: [Tagging] My "weirdly unnatural aversion to relations"

2018-09-30 Thread Tomas Straupis
On 30.09.2018 05:00, Bryan Housel wrote:
> From my own perspective as the main developer on the main editor for
> OSM,

  This is way too exaggerated. While iD is most visible, most data is
created not by iD. And it is not always possible to advice novice user
to use iD. For example iD only supports new "Russian water tagging
scheme" (everything blue is natural=water), so if a country had made a
decision to stick with original "standard OSM water scheme" (with
landuse=reservoir|basin|etc waterway=riverbank) it is impossible to
use iD as it does not support standard OSM water scheme. Note that
Russian water scheme never reached the standard water scheme in
popularity even with iD pushing for it.

  Same goes with "contact:*" scheme and probably a number of other
tagging schemes.

-- 
Tomas

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