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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Walker Bradley-2
>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 <[hidden email]>
Sent: Tuesday, 24 November, 2020 11:11
To: Tag discussion, strategy and related tools <[hidden email]>
Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. water



> Dave F via Tagging <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Tagging mailing list
In reply to this post by Tagging mailing list



Nov 24, 2020, 01:24 by [hidden email]:


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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Tagging mailing list
In reply to this post by Walker Bradley-2
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 [hidden email]:
>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 <[hidden email]>
Sent: Tuesday, 24 November, 2020 11:11
To: Tag discussion, strategy and related tools <[hidden email]>
Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. water


Dave F via Tagging <[hidden email]> 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
https://lists.openstreetmap.org/listinfo/tagging


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


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Walker Bradley-2

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.

 

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 <[hidden email]>
Sent: Tuesday, 24 November, 2020 13:19
To: Tag discussion, strategy and related tools <[hidden email]>
Cc: Mateusz Konieczny <[hidden email]>; 'Tag discussion, strategy and related tools' <[hidden email]>
Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

 

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 [hidden email]:

>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 <[hidden email]>

Sent: Tuesday, 24 November, 2020 11:11

To: Tag discussion, strategy and related tools <[hidden email]>

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

 

 

Dave F via Tagging <[hidden email]> 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

 

_______________________________________________

Tagging mailing list

 

 

_______________________________________________

Tagging mailing list

 


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Tagging mailing list



Nov 24, 2020, 15:09 by [hidden email]:

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:



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Christoph Hormann-2
In reply to this post by Walker Bradley-2


> [hidden email] 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Walker Bradley-2
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 <[hidden email]>
Sent: Tuesday, 24 November, 2020 15:12
To: Tag discussion, strategy and related tools <[hidden email]>
Subject: Re: [Tagging] Extremely long Amtrak route relations / coastline v. water



> [hidden email] 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12