Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[walker.t.bradley]

The needs you post make perfect sense, but as a non-developer, I can't actually 
translate that into a project or estimate time/budget.  If someone else can, 
that would certainly make it easier.  Clearly someone trying to impose 
something on OSM carto is a non-starter and against the community aspect of 
OSM, but I'm sure that within OSM-carto there are some pain points that could 
be smoothed out with limited investment.

-Original Message-
From: Christoph Hormann  
Sent: Tuesday, 24 November, 2020 15:12
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. 
water



> walker.t.brad...@gmail.com hat am 24.11.2020 12:19 geschrieben:
> 
> Is there a wiki page with a "wish-list" of things, with approximate costs 
> where developers could post?  There is likely a disconnect between those 
> willing to pay, and those who could actually scrounge up the money.  Thus, 
> once consensus on what changes are needed has been achieved, we can scrounge 
> for money?

There is certainly a deficit in comprehensive communication of the big tasks 
that are currently not being addressed in and around OSM-Carto.  Part of the 
reason for that is that most OSM-Carto maintainers are doing their work there 
as a hobby and are not very interested in paid OSM-Carto work specifically.  
That also means someone paying a developer for implementing something for 
OSM-Carto does not guarantee you that this will make it into OSM-Carto.  The 
maintainers still reserve the right to review changes for their suitability for 
the project.  See also

https://www.openstreetmap.org/user/imagico/diary/393808

where i previously discussed this being an issue for financing of OSM-Carto 
work.

But lets not beat around the bush too much - here from the top of my head a 
quick list of tasks that could be beneficial for improving the quality of the 
style:

* data preprocessing for low zoom level rendering of waterbodies and landcover. 
 I have done some work on that, some of it was already in production use on 
openstreetmapdata.com, not all of it is currently open source but there is 
extensive writeup on my blog and website.
* importance rating features based on their context.  This includes the widely 
discussed bay and strait rendering matter but also things like airports, 
populated places, peaks etc.
* boundary relation preprocessing.  This includes things like topologically 
consistent line simplification, topological simplification, unification of 
different forms of coastal boundary representation.
* aggregation and importance rating of highway and railway networks based on 
connectivity functions for higher quality low zoom rendering.  There is quite a 
lot of pre-existing work on the aggregation part but much of this does not 
scale or is robust enough for use on a global level of course.
* redesigning the POI and label layers of OSM-Carto for consistent 
prioritization.  There are multiple different levels of radicalism at which 
this could be approached.  This is the most important technical todo within 
OSM-Carto IMO that does not have direct use also beyond that style.

Regarding the volume of work required for these - that depends a lot on how 
you'd define the scope of work in each of the cases.  In those cases where no 
or very little pre-existing work exists it is probably wise to start with a 
proof-of-concept development before actually planning and working on a 
production ready implementation.

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

___
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] Extremely long Amtrak route relations / coastline v. water

[Christoph Hormann]

> walker.t.brad...@gmail.com hat am 24.11.2020 12:19 geschrieben:
> 
> Is there a wiki page with a "wish-list" of things, with approximate costs 
> where developers could post?  There is likely a disconnect between those 
> willing to pay, and those who could actually scrounge up the money.  Thus, 
> once consensus on what changes are needed has been achieved, we can scrounge 
> for money?

There is certainly a deficit in comprehensive communication of the big tasks 
that are currently not being addressed in and around OSM-Carto.  Part of the 
reason for that is that most OSM-Carto maintainers are doing their work there 
as a hobby and are not very interested in paid OSM-Carto work specifically.  
That also means someone paying a developer for implementing something for 
OSM-Carto does not guarantee you that this will make it into OSM-Carto.  The 
maintainers still reserve the right to review changes for their suitability for 
the project.  See also

https://www.openstreetmap.org/user/imagico/diary/393808

where i previously discussed this being an issue for financing of OSM-Carto 
work.

But lets not beat around the bush too much - here from the top of my head a 
quick list of tasks that could be beneficial for improving the quality of the 
style:

* data preprocessing for low zoom level rendering of waterbodies and landcover. 
 I have done some work on that, some of it was already in production use on 
openstreetmapdata.com, not all of it is currently open source but there is 
extensive writeup on my blog and website.
* importance rating features based on their context.  This includes the widely 
discussed bay and strait rendering matter but also things like airports, 
populated places, peaks etc.
* boundary relation preprocessing.  This includes things like topologically 
consistent line simplification, topological simplification, unification of 
different forms of coastal boundary representation.
* aggregation and importance rating of highway and railway networks based on 
connectivity functions for higher quality low zoom rendering.  There is quite a 
lot of pre-existing work on the aggregation part but much of this does not 
scale or is robust enough for use on a global level of course.
* redesigning the POI and label layers of OSM-Carto for consistent 
prioritization.  There are multiple different levels of radicalism at which 
this could be approached.  This is the most important technical todo within 
OSM-Carto IMO that does not have direct use also beyond that style.

Regarding the volume of work required for these - that depends a lot on how 
you'd define the scope of work in each of the cases.  In those cases where no 
or very little pre-existing work exists it is probably wise to start with a 
proof-of-concept development before actually planning and working on a 
production ready implementation.

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

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Mateusz Konieczny via Tagging]

Nov 24, 2020, 15:09 by walker.t.brad...@gmail.com:

>
> I’ve seen the micro grants, I’m not talking about funding from OSM 
> Foundation.  Basically if someone could identify a solution to some of the 
> problems that come up in this tagging thread like “updating how X rendering 
> process works”, and the community agrees, an appropriate developer(s) could 
> be hired to fix that, which would enable other things.
>
>
I know, I linked it because it was closest thing to what was described and it 
gives some perspective
about likely funding needed.

> For example more complete and systematic local languages translation, 
> “better” cartographic representation (two weeks ago conversation), more 
> complicated water tags (a frequent topic here), whatever.  
>
Note that the best project would be something that does not require changes to 
mapped 
data to avoid various conflicts.

Not sure what you mean by "more complicated water tags" but it sounds like a 
poor fit,
if by "more complete and systematic local languages translation" you mean
"setting up rendering server that shows name:en/name:pl/named:de/name:whatever 
tags,
not just name tag" then it sounds like a something that has decent chances to 
succed.

> The only “back-end cleanup” proposal I see is the > denied osm2pgsql 
> development 
> >
>  .
>
Note that it was funded by OSMF shortly after:
https://lists.openstreetmap.org/pipermail/talk/2020-August/085174.html


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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[walker.t.bradley]

I’ve seen the micro grants, I’m not talking about funding from OSM Foundation.  
Basically if someone could identify a solution to some of the problems that 
come up in this tagging thread like “updating how X rendering process works”, 
and the community agrees, an appropriate developer(s) could be hired to fix 
that, which would enable other things.  For example more complete and 
systematic local languages translation, “better” cartographic representation 
(two weeks ago conversation), more complicated water tags (a frequent topic 
here), whatever.  The only “back-end cleanup” proposal I see is the denied 
osm2pgsql development 
<https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Osm2pgsql_development>
 . 

 

OSMF states that they prefer enabling volunteers, vice paying for work, and 
these are capped at 5k EUR.  There are ways that work could be directly paid 
for, which would better enable the entire community.

 

From: Mateusz Konieczny via Tagging  
Sent: Tuesday, 24 November, 2020 13:19
To: Tag discussion, strategy and related tools 
Cc: Mateusz Konieczny ; 'Tag discussion, strategy and 
related tools' 
Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. 
water

 

https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020 would kind of 
illustrate

what kind of money was requested for OSM-related projects.

 

Some of that was pure or nearly pure software development, though most of them

are either funded or were a quite poor proposals.

 

Nov 24, 2020, 12:19 by walker.t.brad...@gmail.com 
<mailto:walker.t.brad...@gmail.com> :

>Why is nothing in that direction in OSM-Carto right now? Because no one so far 
>has invested the volunteer time to do so an no one has invested the money to 
>pay someone qualified to do so either. And a large number of people consider 
>the status quo as good enough. "The good enough is an enemy of the great" is a 
>very common pattern in map style development.

 

Is there a wiki page with a "wish-list" of things, with approximate costs where 
developers could post? There is likely a disconnect between those willing to 
pay, and those who could actually scrounge up the money. Thus, once consensus 
on what changes are needed has been achieved, we can scrounge for money?

 

Walker KB

 

-Original Message-

From: Christoph Hormann mailto:o...@imagico.de> > 

Sent: Tuesday, 24 November, 2020 11:11

To: Tag discussion, strategy and related tools mailto:tagging@openstreetmap.org> >

Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. 
water

 

 

Dave F via Tagging mailto:tagging@openstreetmap.org> > hat am 24.11.2020 01:24 geschrieben:

 

Yes, but the demand was still made &

 

So what? Someone (an individual, not 'OSM-Carto' as a whole) made a suggestion 
(and not a demand) that turned out to not be such a good idea and therefore did 
not achieve consensus.

the solution of writing competent

code to enable the proposal was never implemented, so your point is?

 

I am not sure what you mean here. One of the problem of tagging boundaries on 
ways and one of the main reason why the idea did not reach consensus is that it 
does not solve any of the rendering problems w.r.t. boundaries in substance.

 

Code for processing OSM boundary data for cartographic applications exists. Not 
all of it is open source and much of it is just rough implementations not 
robust enough for routine use. And there are of course very different 
cartographic problems to solve w.r.t. boundary rendering. Why is nothing in 
that direction in OSM-Carto right now? Because no one so far has invested the 
volunteer time to do so an no one has invested the money to pay someone 
qualified to do so either. And a large number of people consider the status quo 
as good enough. "The good enough is an enemy of the great" is a very common 
pattern in map style development.

 

--

Christoph Hormann

http://www.imagico.de/

 

___

Tagging mailing list

Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> 

https://lists.openstreetmap.org/listinfo/tagging

 

 

___

Tagging mailing list

Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> 

https://lists.openstreetmap.org/listinfo/tagging

 

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Mateusz Konieczny via Tagging]

https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020 would kind of 
illustrate
what kind of money was requested for OSM-related projects.

Some of that was pure or nearly pure software development, though most of them
are either funded or were a quite poor proposals.

Nov 24, 2020, 12:19 by walker.t.brad...@gmail.com:

> >Why is nothing in that direction in OSM-Carto right now?  Because no one so 
> >far has invested the volunteer time to do so an no one has invested the 
> >money to pay someone qualified to do so either.  And a large number of 
> >people consider the status quo as good enough.  "The good enough is an enemy 
> >of the great" is a very common pattern in map style development.
>
> Is there a wiki page with a "wish-list" of things, with approximate costs 
> where developers could post?  There is likely a disconnect between those 
> willing to pay, and those who could actually scrounge up the money.  Thus, 
> once consensus on what changes are needed has been achieved, we can scrounge 
> for money?
>
> Walker KB
>
> -Original Message-
> From: Christoph Hormann  
> Sent: Tuesday, 24 November, 2020 11:11
> To: Tag discussion, strategy and related tools 
> Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. 
> water
>
>
>
>> Dave F via Tagging  hat am 24.11.2020 01:24 
>> geschrieben:
>>
>> Yes, but the demand was still made &
>>
>
> So what?  Someone (an individual, not 'OSM-Carto' as a whole) made a 
> suggestion (and not a demand) that turned out to not be such a good idea and 
> therefore did not achieve consensus.
>
>> the solution of writing competent
>> code to enable the proposal was never implemented, so your point is?
>>
>
> I am not sure what you mean here.  One of the problem of tagging boundaries 
> on ways and one of the main reason why the idea did not reach consensus is 
> that it does not solve any of the rendering problems w.r.t. boundaries in 
> substance.
>
> Code for processing OSM boundary data for cartographic applications exists.  
> Not all of it is open source and much of it is just rough implementations not 
> robust enough for routine use.  And there are of course very different 
> cartographic problems to solve w.r.t. boundary rendering.  Why is nothing in 
> that direction in OSM-Carto right now?  Because no one so far has invested 
> the volunteer time to do so an no one has invested the money to pay someone 
> qualified to do so either.  And a large number of people consider the status 
> quo as good enough.  "The good enough is an enemy of the great" is a very 
> common pattern in map style development.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Mateusz Konieczny via Tagging]

Nov 24, 2020, 01:24 by tagging@openstreetmap.org:

>
>
> On 22/11/2020 22:27, Christoph Hormann wrote:
>
>> Exactly. It also shows how we in OSM traditionally make decisions about 
>> tagging. An idea to change tagging practice was suggested - on an open 
>> channel for everyone to read and comment on without hurdles and with an 
>> archive that allows us now to read up on things years later. It was 
>> discussed and arguments and reasoning were provided both for and against the 
>> idea and based on that we reached consensus that it was a bad idea and it 
>> was abandoned.
>>
>
> Yes, but the demand was still made & the solution of writing competent code 
> to enable the proposal was never implemented, so your point is?
>
You claim was that:
- this code is trivially easy to implement
- that developers failed to do so "purely because they can't be bothered/not 
competent enough"
- and presented as something happening right now, without mention that it 
refers to something
suggested/proposed/demanded year ago and abandoned also years ago

And you topped it with 
"if developers are offended at receiving suggestions on how to improve their 
software, or even have it criticized, then they should rescind it."

Yes, I am offended. But it was not a suggestion. It was a baseless insult and 
misrepresentation of
a situation, that is generally not useful or desirable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[walker.t.bradley]

>Why is nothing in that direction in OSM-Carto right now?  Because no one so 
>far has invested the volunteer time to do so an no one has invested the money 
>to pay someone qualified to do so either.  And a large number of people 
>consider the status quo as good enough.  "The good enough is an enemy of the 
>great" is a very common pattern in map style development.

Is there a wiki page with a "wish-list" of things, with approximate costs where 
developers could post?  There is likely a disconnect between those willing to 
pay, and those who could actually scrounge up the money.  Thus, once consensus 
on what changes are needed has been achieved, we can scrounge for money?

Walker KB

-Original Message-
From: Christoph Hormann  
Sent: Tuesday, 24 November, 2020 11:11
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. 
water



> Dave F via Tagging  hat am 24.11.2020 01:24 
> geschrieben:
> 
> Yes, but the demand was still made &

So what?  Someone (an individual, not 'OSM-Carto' as a whole) made a suggestion 
(and not a demand) that turned out to not be such a good idea and therefore did 
not achieve consensus.

> the solution of writing competent
> code to enable the proposal was never implemented, so your point is?

I am not sure what you mean here.  One of the problem of tagging boundaries on 
ways and one of the main reason why the idea did not reach consensus is that it 
does not solve any of the rendering problems w.r.t. boundaries in substance.

Code for processing OSM boundary data for cartographic applications exists.  
Not all of it is open source and much of it is just rough implementations not 
robust enough for routine use.  And there are of course very different 
cartographic problems to solve w.r.t. boundary rendering.  Why is nothing in 
that direction in OSM-Carto right now?  Because no one so far has invested the 
volunteer time to do so an no one has invested the money to pay someone 
qualified to do so either.  And a large number of people consider the status 
quo as good enough.  "The good enough is an enemy of the great" is a very 
common pattern in map style development.

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

___
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] Extremely long Amtrak route relations / coastline v. water

[Christoph Hormann]

> Dave F via Tagging  hat am 24.11.2020 01:24 
> geschrieben:
> 
> Yes, but the demand was still made & 

So what?  Someone (an individual, not 'OSM-Carto' as a whole) made a suggestion 
(and not a demand) that turned out to not be such a good idea and therefore did 
not achieve consensus.

> the solution of writing competent 
> code to enable the proposal was never implemented, 
> so your point is?

I am not sure what you mean here.  One of the problem of tagging boundaries on 
ways and one of the main reason why the idea did not reach consensus is that it 
does not solve any of the rendering problems w.r.t. boundaries in substance.

Code for processing OSM boundary data for cartographic applications exists.  
Not all of it is open source and much of it is just rough implementations not 
robust enough for routine use.  And there are of course very different 
cartographic problems to solve w.r.t. boundary rendering.  Why is nothing in 
that direction in OSM-Carto right now?  Because no one so far has invested the 
volunteer time to do so an no one has invested the money to pay someone 
qualified to do so either.  And a large number of people consider the status 
quo as good enough.  "The good enough is an enemy of the great" is a very 
common pattern in map style development.

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

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

On 22/11/2020 22:27, Christoph Hormann wrote:
Exactly. It also shows how we in OSM traditionally make decisions 
about tagging. An idea to change tagging practice was suggested - on 
an open channel for everyone to read and comment on without hurdles 
and with an archive that allows us now to read up on things years 
later. It was discussed and arguments and reasoning were provided both 
for and against the idea and based on that we reached consensus that 
it was a bad idea and it was abandoned.


Yes, but the demand was still made & the solution of writing competent 
code to enable the proposal was never implemented, so your point is?


DaveF


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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Kevin Kenny]

On Sun, Nov 22, 2020 at 8:04 PM Brian M. Sperlongano 
wrote:

> Therefore, a holistic solution is needed for large objects.  Setting an
> api limit is good because it gives consumers a guarantee about the
> worst-case object they might have to handle.  However, it must also be
> combined with a replacement mechanism for representing large objects.  The
> 2,000 node limit for a way is fine because longer ways can be combined via
> relations.  If the relation member limit were capped, you create a class of
> objects that cannot be represented in the data set.
>

We've already substantially solved that problem for routes. Super-relations
seem to work well, and only rarely do we even need a three-level hierarchy.
As Steve points out, we could go deeper, but there's no need.

>
> What I think is missing is a way to store huge multipolygons in such a way
> that they can be worked with in a piecemeal way.  The answer that
> immediately comes to mind is a scheme where large objects are represented
> as relations of relations, where portions of a huge multipolygon are
> chopped up into fragments and stored in subordinate multipolygon
> relations.  This hierarchy could perhaps nest several levels if needed.
> Now a 40,000 member relation could be composed of 200 relations of 200
> members each, with each subordinate relation member being a valid
> multipolygon with disjoint or adjacent portions of the overall geometry.
>
> Then, an editor could say "here is a large relation, I've drawn bounding
> boxes for the 200 sub-relations, if you select one, I'll load its data and
> you can edit just that sub-relation".
>

> This could *almost* work under the current relation scheme (provided new
> relation types are invented to cover these types of data structures, and
> consumers roger up to supporting such hierarchical relations).  The thing
> that makes this fail for interactive data consumers (such as an editor or a
> display) is that *there's no way to know where relation members are,
> spatially, within the relation*.  The api does not have a way to say
> "what is the bounding box of this object?"  A consumer would need to
> traverse down through the hierarchy to compute the inner bounding boxes,
> which defeats the purpose of subdividing it in the first place.
>

You're right that it's a problem, but you misdiagnose the details. Rather
than identifying bounding boxes, which is easy, the problem comes down to
identifying topology - is a given point in space on the inside or outside
of the multipolygon? The minimal information needed when that question is
asked is one of two things. You need to know either the 'winding number' -
essentially, if you draw a mathematical ray from the point to infinity in a
given direction, how many times do you cross the boundary of the region?
(Odd = inside, even = outside).  The second is to add a requirement to the
data model that the boundaries of regions must follow a particular winding
direction; most GIS systems use the "right hand rule" of specifying that as
you proceed along a boundary way, the interior of a relation should be on
your right.

The second rule is by far the easiest to implement. Unfortunately, it's
also inconsistent with OSM's base data model. The problem is that we do not
necessarily require multipolygons to be sorted in any particular order
(depending on client software to order them if necessary), nor do we
require the boundary ways to proceed in any particular direction with
respect to the multipolygon.  In fact, we cannot require the boundary ways
to proceed in a particular direction, since shared ways between adjacent
multipolygons are a fairly common practice. The practice is somewhat
controversial; nevertheless, it seems like a good idea when the adjoining
regions by their nature are both known to touch and known to be mutually
exclusive. The lines that separate landuse from landuse, landcover from
landcover, administrative region from administrative region, land from
water, or cadastral parcel from cadastral parcel (where cadastre is
accepted, as it is with objects like public recreational land).

Except for monsters such as the World Ocean (the coastline is a perpetual
headache), seas, and objects with extremely complex topology, the problem
is somewhat manageable. A single 'ring' (the cycle of contiguous ways,
inner or outer, that form one region of a multipolygon) or a single
'complex polygon' (an outer way and any inner ways subordinate to it) are
generally quite manageable in terms of data volume.  I can edit shorelines
of the Great Lakes, for instance, with some confidence, by loading into
JOSM all the data near the single stretch of shoreline that I'm working on,
plus the entire outer perimeter of the lake (using the 'download incomplete
members' function); having the shoreline outside the immediate region of
interest doesn't stress the memory even of a somewhat obsolete laptop
computer. Not all editors are as competent with managing large relations 

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[stevea]

Brian, as someone who worked on these national rail relations (and still does, 
to some extent, though only around the edges), I agree with you that "very 
large" relations (in Amtrak we say that one route is >2500 relations and meets 
that standard of "very large") do exist.  And, they are unwieldy, especially 
for those who edit with "only" moderate (or less!) compute resources.  Such 
demands are partly why open mapping didn't happen until the 21st century:  our 
computers are just keeping up (as they do:  compute power fills niches of 
computing that the tech / hardware / software development only catches up to, 
it then begins to be used for those applications).  Desktop computers and Java 
/ early JOSM / Potlatch 1 and 2 around 2005 were an OK match for each other.  
OSM has grown these from there.  (Nicely, in my opinion, though there are 
always newer, faster technologies and software platforms to harness them).

AI on "bigger iron" is real today with what Facebook is doing in OSM with its 
machine learning toolchain.  Data structures must keep up.  Physics had to look 
to the ancients and see that 10 to the 100th power wasn't so big, there are 
Sanskrit words from long ago for what we consider fairly large numbers today.  
And so OSM must keep up with inventing its future (of data structures) capable 
of "keeping up with Earth as data."

Super-relations do seem the way to go:  so far, so good.  I don't know about 
"200 deep" but as things go much wider (but not much deeper than perhaps 
several "relation-levels" for now, let's say "great-great-grandparents" I can 
hold in my mind for now), they seem like they will suffice.  If we need that 
many "dimensions" (relations "deep," not necessarily wide, as data simply ARE 
wide, not necessarily deep, though we should be prepared to go deep if we need 
to) we can, as you say "go hundreds deep."

But yes, doing so both preserves the legacy of relations of relations (and even 
"of relations...ad infinitum") we don't need to do that very often.  However, 
in train routes, there are now super-routes that exist that are "grandparents," 
so three deep.  This seems to be happening with bicycle routes, too and perhaps 
road routes, I'm not quite enough of a road geek to say yes or no, but I think 
so.

Luckily, relational databases (like OSM) give us ways to link them all 
together, "walking up and down the chain of hierarchy."  Some software, use 
cases, routers, whatever...will be sophisticated to do this walking and "be 
smarter for doing so," presenting a much fuller, richer, complete universe of 
data, some (software) will not and will present a more "flat" view of the world 
(OSM's data, really, similar to looking at ways or nodes only but ignoring 
relations).

We both have and use methods to do this, so, "good."  But you are right to be 
talking about it, as data consumers, use cases, "those downstream" will need to 
have their antennae tuned to be paying attention to these "more sophisticated" 
ways of embedding hierarchy in our data.  We have been doing this since 
relations were developed in OSM, some data consumer softwares pay attention, 
some don't.  It's a real thing.  I like, for example, the way that Lonvia (in 
the www.waymarkedtrails.org series of overlay layers) allows and displays a 
view of relations and super-relations in the table of routes presented.  That's 
called "paying attention" and it's great when developers pay attention to these 
richnesses in the structure of our (sometimes hierarchical) data (so, thank you 
again, Sarah).  Being aware there IS a hierarchy is the first step to "walking 
it" and presenting its complexity to data consumers in ways that make sense for 
that sort of structure.

We'll solve coastline / water edges, it'll be mostly legacy (we've done it like 
this for quite some time) with a bit of "new methods of thinking about things" 
going forward.  This is how OSM works.  Talking about it is fine.  We're 
generating light, not heat.

A lot of people (Simon, Phake, Dave F, Clay, Mateusz, Christoph, Brian, Seth, 
Richard, more...) are quite right here.  Let's listen to each other.  We're all 
much MORE in agreement than disagreement.

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Brian M. Sperlongano]

As time goes on, we will encounter increasingly accurate and resolute
mechanisms for surveying things like coastlines and land cover.  For
example, there are discussions about whether to use things like AI and
machine learning to produce such data.  The demand for ways to deal with
larger objects will only grow in the future

Therefore, a holistic solution is needed for large objects.  Setting an api
limit is good because it gives consumers a guarantee about the worst-case
object they might have to handle.  However, it must also be combined with a
replacement mechanism for representing large objects.  The 2,000 node limit
for a way is fine because longer ways can be combined via relations.  If
the relation member limit were capped, you create a class of objects that
cannot be represented in the data set.

What I think is missing is a way to store huge multipolygons in such a way
that they can be worked with in a piecemeal way.  The answer that
immediately comes to mind is a scheme where large objects are represented
as relations of relations, where portions of a huge multipolygon are
chopped up into fragments and stored in subordinate multipolygon
relations.  This hierarchy could perhaps nest several levels if needed.
Now a 40,000 member relation could be composed of 200 relations of 200
members each, with each subordinate relation member being a valid
multipolygon with disjoint or adjacent portions of the overall geometry.

Then, an editor could say "here is a large relation, I've drawn bounding
boxes for the 200 sub-relations, if you select one, I'll load its data and
you can edit just that sub-relation".

This could *almost* work under the current relation scheme (provided new
relation types are invented to cover these types of data structures, and
consumers roger up to supporting such hierarchical relations).  The thing
that makes this fail for interactive data consumers (such as an editor or a
display) is that *there's no way to know where relation members are,
spatially, within the relation*.  The api does not have a way to say "what
is the bounding box of this object?"  A consumer would need to traverse
down through the hierarchy to compute the inner bounding boxes, which
defeats the purpose of subdividing it in the first place.


On Sun, Nov 22, 2020 at 1:44 PM Simon Poole  wrote:

>
> Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano:
> > ..
> >
> > I like the idea of an api limit, though we would need a strategy to
> > deal with existing large objects.
> > ..
>
> This is, "surprise", not a new topic. There are certain issues with the
> semantics of relations which make this slightly more involved as the
> maximum node limit on ways.
>
> See
>
> - https://github.com/openstreetmap/openstreetmap-website/issues/1711
>
> - https://github.com/zerebubuth/openstreetmap-cgimap/pull/174
>
> With the later giving some insights in to why simply declaring a limit
> is not a good idea. But putting a bound in place and expecting all tools
> to be handle relations up to that size (just as we currently do with
> ways) would be a good thing to improve robustness of the whole system.
>
> Simon
>
> ___
> 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] Extremely long Amtrak route relations / coastline v. water

[Christoph Hormann]

> Mateusz Konieczny via Tagging  hat am 22.11.2020 
> 20:49 geschrieben:
> 
> > https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html
> Yes, long time ago there was a problematic idea that was abandoned.

Exactly.  It also shows how we in OSM traditionally make decisions about 
tagging.  An idea to change tagging practice was suggested - on an open channel 
for everyone to read and comment on without hurdles and with an archive that 
allows us now to read up on things years later.  It was discussed and arguments 
and reasoning were provided both for and against the idea and based on that we 
reached consensus that it was a bad idea and it was abandoned.

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

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Mateusz Konieczny via Tagging]

Nov 22, 2020, 19:00 by tagging@openstreetmap.org:

> I'm surprised you think that as you were a contributor to the discussions:
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/3102
>
This is a closed, not implemented PR. So it is not a case of
"OSM-carto demanding boundaries on ways".



> https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html
>
Yes, long time ago there was a problematic idea that was abandoned.

Describing something like that over two years later as 
"OSM-carto demanding boundaries on ways" - in present tense and 
with claim that it is technical issue caused by incompetent programmers
is misleading at best.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Mateusz Konieczny via Tagging]

Nov 22, 2020, 19:34 by tagging@openstreetmap.org:

>
>
> On 22/11/2020 18:12, Clay Smalley  wrote:
>
>> On Sun, Nov 22, 2020 at 11:12 AM Dave F via  Tagging <>> 
>> tagging@openstreetmap.org>> >  wrote:
>>
>>>
>>>
>>> Contributing to the database (also *volunteers*) are  expected 
>>> to map to a certain standard. There shouldn't be  a reason to 
>>> expect develops not to do the same.
>>>
>>
>> If it's so easy, why don't you write the "few lines ofcode" 
>> necessary to fix this issue?
>>
> I did. Note the response.
>  > 
> https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-372455636
>
The mention was about "few lines ofcode" necessary to fix this issue

Not about lines of code making something similar on a different software stack,
that is not fixing the issue at all.

And the very next comment is

> Exactly, however there is no way to express that in CartoCSS.

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Phake Nick]

Excuse me, what is the limitation here against tagging "Extremely long
Amtrak relations"? Some of those Amtrak services, while long, in my
knowledge are still far from the longest in the OSM database, like they're
shorter than the train route between Moscow to Pyongyang, which have been
tagged as a regular relationship with no observable problem to me.
In my opinion, since these long Amtrak service are still just a single
services, with no break or cha.ge of train or change of train number
in-between, it seems outright bogus to tag them separately, and would
confuse anyway who wish to use OSM data to provide navigation involving
such train routes.

在 2020年11月22日週日 19:29，Richard Fairhurst  寫道：

> [cross-posted to talk-us@ and tagging@, please choose your follow-ups
> wisely]
>
> Brian M. Sperlongano wrote:
> > It seems that we are increasingly doing things to simplify the
> > model because certain tooling can't handle the real level of
> > complexity that exists in the real world.  I'm in favor of fixing
> > the tooling rather than neutering the data.
>
> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
> fix", though I fear I may be disappointed.
>
> More broadly, we need to nip this "oh just fix the tools" stuff in the
> bud.
>
> OSM optimises for the mapper, because mappers are our most valuable
> resource. That's how it's always been and that's how it should be.
>
> But that does not mean that volunteer tool authors should rewrite their
> tools to cope with the 0.1% case; nor that it is reasonable for mappers to
> make stuff ever more complex and expect developers to automatically fall in
> line; nor that any given map has a obligation to render this 0.1%, or
> indeed, anything that the map's creator doesn't want to render.
>
> The Tongass National Forest is not "in the real world", it is an
> artificial administrative construct drawn up on some bureaucrat's desk.
> It's not an actual forest where the boundaries represent a single
> contiguous mass of trees. Nothing is lost or "neutered" by mapping it as
> several relations (with a super-relation for completeness if you insist),
> just as nothing is lost by tagging Chesapeake Bay with the series of
> letters "c","o","a","s","t","l","i","n" and "e".
>
> Richard
> ___
> 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] Extremely long Amtrak route relations / coastline v. water

[Simon Poole]

Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano:

..

I like the idea of an api limit, though we would need a strategy to 
deal with existing large objects.

..


This is, "surprise", not a new topic. There are certain issues with the 
semantics of relations which make this slightly more involved as the 
maximum node limit on ways.


See

- https://github.com/openstreetmap/openstreetmap-website/issues/1711

- https://github.com/zerebubuth/openstreetmap-cgimap/pull/174

With the later giving some insights in to why simply declaring a limit 
is not a good idea. But putting a bound in place and expecting all tools 
to be handle relations up to that size (just as we currently do with 
ways) would be a good thing to improve robustness of the whole system.


Simon



OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

On 22/11/2020 18:12, Clay Smalley wrote:
On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging 
mailto:tagging@openstreetmap.org>> wrote:




Contributing to the database (also *volunteers*) are expected to
map to a certain standard. There shouldn't be a reason to expect
develops not to do the same.


If it's so easy, why don't you write the "few lines of code" necessary 
to fix this issue?

I did. Note the response.
https://github.com/gravitystorm/openstreetmap-carto/pull/3102#issuecomment-372455636


Desiring relations to list in their entirety is *not* a "0.1%
case". Splitting them into 'super relations' should not be the
desired, final solution.


Amtrak routes, like many other public transit routes, are already 
split into super-relations (see [1], [2]).


Yes. I've done it myself on UK bicycle routes, but only out of 
necessity, due to the software limitation, not, as I stated, from any 
desire. It would be much less error prone with tags & ways being added 
to the wrong relations.


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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Clay Smalley]

On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> On 22/11/2020 11:24, Richard Fairhurst wrote:
>
>
> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
> fix", though I fear I may be disappointed.
>
> More broadly, we need to nip this "oh just fix the tools" stuff in the
> bud. (etc)
>
>
> Likewise we need to stop software developers from expecting contributors
> to add data purely because they can't be bothered/not competent enough to
> write a few lines of code. (OSM-carto demanding boundaries on ways &
> numerous routers expecting multiple foodways to criss-cross pedestrian
> areas, are just two examples)
>
> Contributing to the database (also *volunteers*) are expected to map to a
> certain standard. There shouldn't be a reason to expect develops not to do
> the same.
>

If it's so easy, why don't you write the "few lines of code" necessary to
fix this issue?


> Desiring relations to list in their entirety is *not* a "0.1% case".
> Splitting them into 'super relations' should not be the desired, final
> solution.
>

Amtrak routes, like many other public transit routes, are already split
into super-relations (see [1], [2]). This is a non-issue. I've already
decided to split up long-distance Amtrak routes into more manageable
chunks, especially since I'm the one who takes on most of the work of
managing them. My original question was *how* to split them up, not
*whether* to split them. I'm not convinced that attempts to persuade me not
to do so are helpful in any way, so I'm going to consider them off-topic
and ignore them.

-Clay

[1] https://wiki.openstreetmap.org/wiki/Relation:route_master

[2] https://wiki.openstreetmap.org/wiki/Amtrak
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

I'm surprised you think that as you were a contributor to the discussions:

https://github.com/gravitystorm/openstreetmap-carto/pull/3102

https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html

DaveF



On 22/11/2020 16:32, Christoph Hormann wrote:



Dave F via Tagging  hat am 22.11.2020 17:08 
geschrieben:

[...] OSM-carto demanding boundaries on ways

???

I am smelling fake news here.




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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Mateusz Konieczny via Tagging]

Nov 22, 2020, 17:08 by tagging@openstreetmap.org:

> Likewise we need to stop software developers from expectingcontributors 
> to add data purely because they can't be bothered/notcompetent enough to 
> write a few lines of code. (OSM-carto demandingboundaries on ways)
>
[citation needed] for OSM-carto demandingboundaries on ways

Also [citation needed] for OSM-Carto support for boundary relations being 
extremely easy to implement

>  & numerous routers expecting multiplefoodways to criss-cross pedestrian 
> areas, are just two examples) 
>
Also [citation needed] for that reason is
"can't be bothered/notcompetent enough to write a few lines of code" 

>  If developers are offended at receiving suggestions on how toimprove 
> their software, or even have it criticized, then they shouldrescind it. 
>
If you insult others, claim that something is trivial to implement (it is not),
while something you demand is implemented already and suggest that
anyone offended by your comments should stop releasing software

I would say that it is quite poor way to encourage volunteer
contributors to implement what you want.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Brian M. Sperlongano]

I agree.  I removed such duplicate tagging from my area some time ago, and
it has not affected anything.

I even went so far as to draft a proposal to change that recommendation.

https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/proposals/Boundary_relation_way_members

On Sun, Nov 22, 2020, 11:37 AM Christoph Hormann  wrote:

>
>
> > Dave F via Tagging  hat am 22.11.2020 17:08
> geschrieben:
> >
> > [...] OSM-carto demanding boundaries on ways
>
> ???
>
> I am smelling fake news here.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Extremely long Amtrak route relations / coastline v. water

[Brian M. Sperlongano]

Super relations could also solve problems like the Tongass National
Forest.  By crafting a relation of relations, you still preserve the
ability to have one tagged super-object represent one complex thing in real
life, but with natural cut points so that any consumer can choose to deal
with in in manageable stages.  No different from the 2000 node limit on
ways.  There should still be a top level object that represents the whole
thing.

I like the idea of an api limit, though we would need a strategy to deal
with existing large objects.

On Sun, Nov 22, 2020, 11:24 AM Seth Deegan  wrote:

> I recently found out about the Extremely long Amtrak route relations from
> clay_c.
>
> Your message is a bit confusing at first but I think you are proposing
> that relations and super-relations should be used more-often to reduce the
> complexity of processing data for data consumers?
>
> In that case, I would support an API limit on the number of members in a
> relation.
> I agree that developers shouldn't have to handle this burden.
>
> In response to DaveF's comment:
>
>> Actually, splitting way because software can't handle it, is making the
>> database more complex.
>
>
> Yes, but benefits outweigh the costs.
> If the editors did this automatically and still made the data
> interpretable, this wouldn't be an issue.
>
> Sorry if I misinterpreted the conversation.
>
> On Sun, Nov 22, 2020 at 5:29 AM Richard Fairhurst 
> wrote:
>
>> [cross-posted to talk-us@ and tagging@, please choose your follow-ups
>> wisely]
>>
>> Brian M. Sperlongano wrote:
>> > It seems that we are increasingly doing things to simplify the
>> > model because certain tooling can't handle the real level of
>> > complexity that exists in the real world.  I'm in favor of fixing
>> > the tooling rather than neutering the data.
>>
>> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
>> fix", though I fear I may be disappointed.
>>
>> More broadly, we need to nip this "oh just fix the tools" stuff in the
>> bud.
>>
>> OSM optimises for the mapper, because mappers are our most valuable
>> resource. That's how it's always been and that's how it should be.
>>
>> But that does not mean that volunteer tool authors should rewrite their
>> tools to cope with the 0.1% case; nor that it is reasonable for mappers to
>> make stuff ever more complex and expect developers to automatically fall in
>> line; nor that any given map has a obligation to render this 0.1%, or
>> indeed, anything that the map's creator doesn't want to render.
>>
>> The Tongass National Forest is not "in the real world", it is an
>> artificial administrative construct drawn up on some bureaucrat's desk.
>> It's not an actual forest where the boundaries represent a single
>> contiguous mass of trees. Nothing is lost or "neutered" by mapping it as
>> several relations (with a super-relation for completeness if you insist),
>> just as nothing is lost by tagging Chesapeake Bay with the series of
>> letters "c","o","a","s","t","l","i","n" and "e".
>>
>> Richard
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Thanks,
> Seth
> ___
> 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] Extremely long Amtrak route relations / coastline v. water

[Christoph Hormann]

> Dave F via Tagging  hat am 22.11.2020 17:08 
> geschrieben:
> 
> [...] OSM-carto demanding boundaries on ways

???

I am smelling fake news here.

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

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Seth Deegan]

I recently found out about the Extremely long Amtrak route relations from
clay_c.

Your message is a bit confusing at first but I think you are proposing that
relations and super-relations should be used more-often to reduce the
complexity of processing data for data consumers?

In that case, I would support an API limit on the number of members in a
relation.
I agree that developers shouldn't have to handle this burden.

In response to DaveF's comment:

> Actually, splitting way because software can't handle it, is making the
> database more complex.


Yes, but benefits outweigh the costs.
If the editors did this automatically and still made the data
interpretable, this wouldn't be an issue.

Sorry if I misinterpreted the conversation.

On Sun, Nov 22, 2020 at 5:29 AM Richard Fairhurst 
wrote:

> [cross-posted to talk-us@ and tagging@, please choose your follow-ups
> wisely]
>
> Brian M. Sperlongano wrote:
> > It seems that we are increasingly doing things to simplify the
> > model because certain tooling can't handle the real level of
> > complexity that exists in the real world.  I'm in favor of fixing
> > the tooling rather than neutering the data.
>
> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
> fix", though I fear I may be disappointed.
>
> More broadly, we need to nip this "oh just fix the tools" stuff in the
> bud.
>
> OSM optimises for the mapper, because mappers are our most valuable
> resource. That's how it's always been and that's how it should be.
>
> But that does not mean that volunteer tool authors should rewrite their
> tools to cope with the 0.1% case; nor that it is reasonable for mappers to
> make stuff ever more complex and expect developers to automatically fall in
> line; nor that any given map has a obligation to render this 0.1%, or
> indeed, anything that the map's creator doesn't want to render.
>
> The Tongass National Forest is not "in the real world", it is an
> artificial administrative construct drawn up on some bureaucrat's desk.
> It's not an actual forest where the boundaries represent a single
> contiguous mass of trees. Nothing is lost or "neutered" by mapping it as
> several relations (with a super-relation for completeness if you insist),
> just as nothing is lost by tagging Chesapeake Bay with the series of
> letters "c","o","a","s","t","l","i","n" and "e".
>
> Richard
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Thanks,
Seth
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

On 22/11/2020 11:24, Richard Fairhurst wrote:
[cross-posted to talk-us@ and tagging@, please choose your follow-ups 
wisely]


If you go against the accepted principle of not X-posting on a 
newsgroup, you've no entitlement to lecture how others respond.




Brian M. Sperlongano wrote:
> It seems that we are increasingly doing things to simplify the
> model because certain tooling can't handle the real level of
> complexity that exists in the real world.  I'm in favor of fixing
> the tooling rather than neutering the data.


Actually, splitting way because software can't handle it, is making the 
database more complex.




I sincerely hope "I'm in favor of fixing" translates as "I'm planning 
to fix", though I fear I may be disappointed.


More broadly, we need to nip this "oh just fix the tools" stuff in the 
bud. (etc)


Likewise we need to stop software developers from expecting contributors 
to add data purely because they can't be bothered/not competent enough 
to write a few lines of code. (OSM-carto demanding boundaries on ways & 
numerous routers expecting multiple foodways to criss-cross pedestrian 
areas, are just two examples)


Contributing to the database (also *volunteers*) are expected to map to 
a certain standard. There shouldn't be a reason to expect develops not 
to do the same.


Desiring relations to list in their entirety is *not* a "0.1% case". 
Splitting them into 'super relations' should not be the desired, final 
solution.


If developers are offended at receiving suggestions on how to improve 
their software, or even have it criticized, then they should rescind it.


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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Richard Fairhurst]

[cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely]

Brian M. Sperlongano wrote:
> It seems that we are increasingly doing things to simplify the
> model because certain tooling can't handle the real level of
> complexity that exists in the real world.  I'm in favor of fixing
> the tooling rather than neutering the data.

I sincerely hope "I'm in favor of fixing" translates as "I'm planning to fix", 
though I fear I may be disappointed.

More broadly, we need to nip this "oh just fix the tools" stuff in the bud.

OSM optimises for the mapper, because mappers are our most valuable resource. 
That's how it's always been and that's how it should be.

But that does not mean that volunteer tool authors should rewrite their tools 
to cope with the 0.1% case; nor that it is reasonable for mappers to make stuff 
ever more complex and expect developers to automatically fall in line; nor that 
any given map has a obligation to render this 0.1%, or indeed, anything that 
the map's creator doesn't want to render.

The Tongass National Forest is not "in the real world", it is an artificial 
administrative construct drawn up on some bureaucrat's desk. It's not an actual 
forest where the boundaries represent a single contiguous mass of trees. 
Nothing is lost or "neutered" by mapping it as several relations (with a 
super-relation for completeness if you insist), just as nothing is lost by 
tagging Chesapeake Bay with the series of letters 
"c","o","a","s","t","l","i","n" and "e".

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