Re: [Tagging] Elevated housing estate

2020-11-24 Thread Mateusz Konieczny via Tagging
add location=overhead on buildings and other objects?
https://wiki.openstreetmap.org/wiki/Key:location

https://wiki.openstreetmap.org/wiki/Key:building:min_level 
https://wiki.openstreetmap.org/wiki/Key:building:levels#Buildings_with_parts_that_don.27t_start_at_ground_level
(not sure can it be applied if entire building starts above ground level)

Certainly add also description=* tag with info what is happening here,
maybe with link to this mailing list thread.


Nov 25, 2020, 01:00 by graemefi...@gmail.com:

> How do you tag an area, in this case an entire housing estate!, that is 
> raised up above ground level?
>
> https://www.google.com.au/maps/@-28.065772,153.3799853,3a,15y,117.51h,89.21t/data=!3m6!1e1!3m4!1sN_TJvFHJyLff1E4GmiCSjQ!2e0!7i13312!8i6656?hl=en
> (with the usual not mapping from Google ...)
>
> Just draw the outline of the area & tag it as level=1?
>
> The main entry is via a bridge: > 
> https://www.google.com.au/maps/@-28.0673717,153.3800556,3a,23.4y,28.84h,87.1t/data=!3m6!1e1!3m4!1sBF_8z5ekricuuEFZnUJioQ!2e0!7i13312!8i6656?hl=en>
>  ,
> which is ok, but should all the internal roads also be marked as bridges?
>
> Thanks
>
> Graeme
>

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


Re: [Tagging] Elevated housing estate

2020-11-24 Thread Graeme Fitzpatrick
On Wed, 25 Nov 2020 at 11:20, Joseph Eisenberg 
wrote:

> Is the whole ground level a parking lot or parking structure, perhaps?
>

No.

It's built right beside a Creek, on a flood-plain (yeah, thanks Council!),
so it's done like that so that the apartments are up away from the water
the next time the Creek floods!

Thanks

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


Re: [Tagging] Elevated housing estate

2020-11-24 Thread Joseph Eisenberg
Is the whole ground level a parking lot or parking structure, perhaps?

On Tue, Nov 24, 2020 at 4:03 PM Graeme Fitzpatrick 
wrote:

> How do you tag an area, in this case an entire housing estate!, that is
> raised up above ground level?
>
>
> https://www.google.com.au/maps/@-28.065772,153.3799853,3a,15y,117.51h,89.21t/data=!3m6!1e1!3m4!1sN_TJvFHJyLff1E4GmiCSjQ!2e0!7i13312!8i6656?hl=en
> (with the usual not mapping from Google ...)
>
> Just draw the outline of the area & tag it as level=1?
>
> The main entry is via a bridge:
> https://www.google.com.au/maps/@-28.0673717,153.3800556,3a,23.4y,28.84h,87.1t/data=!3m6!1e1!3m4!1sBF_8z5ekricuuEFZnUJioQ!2e0!7i13312!8i6656?hl=en
> ,
> which is ok, but should all the internal roads also be marked as bridges?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

2020-11-24 Thread Martin Koppenhoefer


sent from a phone

> On 24. Nov 2020, at 18:30, Tom Pfeifer  wrote:
> 
> Following the discussion on how to tag COVID-19 vaccination centres 
> previously on this list,
> I have created a proposal for the vaccination key:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/vaccination


the proposal aims at unifying the tagging for a covid-specific property, but 
which are the suggested main tags? Apart from hospitals, clinics and doctors, 
do we need a specific tag for temporary testing facilities?

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


[Tagging] Elevated housing estate

2020-11-24 Thread Graeme Fitzpatrick
How do you tag an area, in this case an entire housing estate!, that is
raised up above ground level?

https://www.google.com.au/maps/@-28.065772,153.3799853,3a,15y,117.51h,89.21t/data=!3m6!1e1!3m4!1sN_TJvFHJyLff1E4GmiCSjQ!2e0!7i13312!8i6656?hl=en
(with the usual not mapping from Google ...)

Just draw the outline of the area & tag it as level=1?

The main entry is via a bridge:
https://www.google.com.au/maps/@-28.0673717,153.3800556,3a,23.4y,28.84h,87.1t/data=!3m6!1e1!3m4!1sBF_8z5ekricuuEFZnUJioQ!2e0!7i13312!8i6656?hl=en
,
which is ok, but should all the internal roads also be marked as bridges?

Thanks

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


Re: [Tagging] coastline v. water

2020-11-24 Thread Kevin Kenny
On Tue, Nov 24, 2020 at 9:23 AM Christoph Hormann  wrote:

> The problem we have here is that of a widening gap between the goals and
> aspirations of the mapper community - which naturally grow as OSM grows in
> ambitions - and the abilities and engagement in the non-mapping part of the
> community to develop and satisfy similar ambitions in cartographic quality
> without outsourcing the hard part of that work to the mappers.  Too many
> people have followed the illusion for too long that the large corporate OSM
> data users will provide the necessary support in that field while it turns
> out (non-surprisingly in my eyes) that they have neither an interest in
> above average cartographic quality nor in substantially sharing methods and
> competency in the little work they do in that domain.
>

(Brief summary: 1. Many area features are indefinite only at margins that
do not have a significant deleterious effect on statistics when analyzed or
on the understanding of the map when rendered. 2. Topology still matters -
for analyzing or rendering them. 3. Algorithm development needs data to
chew on. Blocking the data while waiting for the algorithms is a 'deadly
embrace.' 4. Mappers are continuing to enter the data for approximate
regions because they understand 1.-3. above. 5. Which argument are you
willing to give up in order not to argue against all progress in this
domain?)

In my earlier message, I was speaking not as a mapper looking to enter
data, nor as a map user looking for a pretty rendering - although I wear
both those hats from time to time - but as a newly-retired applied
mathematician (A.B., mathematics, Dartmouth College, MS in electrical
engineering, Arizona State University, PhD, computer science, University of
Illinois, about forty years of experience with GE, Northrop, Honeywell, and
others), with a reasonable background in computational geometry, thinking
of what challenges I ought to tackle next.

Given that one of my principal avocations is hiking, my chief rendering
interest is not with an endlessly-panning map, as useful as that is; it is
with paper maps where labeling must conform with the neatline.  For those
maps, simply placing a point for 'label painting' near the center of an
indefinite feature is not sufficient. Instead, a first step has to be
calculating the intersection of the area feature with the region of
interest, leading to one of the results: (a) the area is totally within the
region; (b) the area is totally outside the region and may be discarded;
(c) the area intersects the region partially and one or more regions of
intersection must have labels placed individually. The 'one or more' arises
from the fact that a non-convex area feature or a non-convex region of
interest (a rectangle, for instance, with a corner cut out for placement of
a legend) may yield more than one polygon of intersection.

You have on several occasions advanced the argument that the central label
should be enough for this and made a contention that I don't understand
about projecting from the central label of a bay onto the shoreline to
reconstruct the area. With that contention came the implication that the
topological information about an indefinite area would not be needed, if
only the renderers and data analysts worked hard enough. Unless you can
provide me with literature citations to what you have in mind, I'm afraid
that I'll have to dismiss your claim as hand-waving. As far as I can tell,
there is no known way to achieve the result that mappers want - or at least
I want - without the detailed geometry of the partially indefinite area. If
you can provide such citations, I'm eager to follow up with you!

I should digress into the phrase, 'partially indefinite,' that I've already
been using.  For the contentious areas such as the Red Sea, the indefinite
portion about which the controversy arises is typically small, and
typically of a nature where a rough approximation is acceptable to all
users. There is no controversy arising from the shoreline of the Red Sea
except for a trivial amount of border.  Very few claim that the Red Sea
exists only as a social construct. Scientists discuss its hydrology and
ecology in contradistinction to that of the region of the Indian Ocean to
which it connects.  Mariners speak of Port Sudan, Jeddah, Sharm al-Sheikh,
or Eilat as Red Sea ports (Eilat may be further specialised as being a port
on the Gulf of Aqaba, a smaller area that is similarly well-defined; the
relation is one of hierarchy rather than exclusion. (Moving somewhat to the
northwest, I've seen papers on hydrology that have tabulated observations
in rows labeled 'Ionian Sea', 'Ægean Sea', 'Tyrrhenian Sea', 'Adriatic
Sea', and so on. There is _some_ shared understanding that those words have
meanings.)

'Partially indefinite' extends to other features such as peninsulæ (a
mirror image of bays - the indefinite boundary is one of land rather than
water); straits (indefinite water margins at both 

[Tagging] RFC: vaccination / COVID-19 vaccination centres

2020-11-24 Thread Tom Pfeifer

Following the discussion on how to tag COVID-19 vaccination centres previously 
on this list,
I have created a proposal for the vaccination key:

https://wiki.openstreetmap.org/wiki/Proposed_features/vaccination

tom

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


Re: [Tagging] coastline v. water

2020-11-24 Thread Brian M. Sperlongano
> there were some attempts to suggest universally mapping bays with polygons
> rather than nodes previously:
>
>
> https://lists.openstreetmap.org/pipermail/tagging/2014-October/thread.html#19775
>
> which however never reached consensus because of the weighty arguments
> against this idea and because it was always clear that this would be a
> non-sustainable strategy for OSM in the long term.
>

It seems to me that consensus is achieved via three, often overlapping
methods, in no particular order:

1.  The proposal process
2.  What's documented on the wiki
3.  How tagging is actually used by mappers and data consumers

Specific discussions on the tagging lists are not necessarily good
indicators of consensus because they are often dominated by whomever
happens to be shouting the loudest and subscribed to the tagging list at
that moment.

With regard to mapping named bodies of water, possibly with fuzzy
boundaries, using polygons, the wiki documents that this is an acceptable
practice, as long as those polygons aren't too large (though, unhelpfully,
without defining what "too large" means).  As you note, osm-carto supports
this method of tagging for marginal seas, and mappers have adopted such
tagging.

Thus, by wiki, and by actual tagging, and by data consumer usage, there IS
consensus - it is acceptable but not required to tag such things as
polygons.  We should not expect mappers to read the minds of people that
are subscribed to this list or comb through years of mailing list archives
to understand how tagging standards have evolved.  The history of how we
got here is irrelevant -- what matters is what exists now, what problems it
may or may not be causing, and what to do about it going forward.

Since you note that there is not a technical limitation, the argument seems
to boil down to "I don't like the standard of verifiability that other
mappers are using."  That is a perfectly valid opinion to have, but it does
not trump de facto, documented usage.  Given the community acceptance of
polygon mapping for smaller marginal seas, it would seem that a formal
proposal is the minimum standard required for documenting that there is
consensus to change de facto usage.

If this is a truly bad idea, and the arguments against such mapping are so
strong, it should be a no-brainer to draft a proposal laying out such
arguments so that the broader community can consider them and demonstrate
true consensus.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-24 Thread 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

2020-11-24 Thread 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

2020-11-24 Thread 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] coastline v. water

2020-11-24 Thread Christoph Hormann
There seems to be quite a lot of anger and animosity in here - paired and in 
parts probably caused by a very selective and in parts flat out wrong 
perception of history so i will try to sketch quickly how the development of 
mapping of names of parts of waterbodies (that is mostly bays and straits) in 
OSM developed historically.

For a long time - until a few years back - these features were overwhelmingly 
mapped with nodes.  This was consensus, not because of technical constraints 
disallowing something else, but because of the realization that in the vast 
majority of cases this is perfectly sufficient to document all verifiable 
information available about the feature in question.  Practically in 2016 there 
were about 5 percent of all bay features mapped with polygons:

https://github.com/gravitystorm/openstreetmap-carto/issues/2068#issuecomment-191677580

which - generously estimated - probably matches about the percentage of cases 
where you could argue that with a polygon you could record some verifiable 
information that cannot recorded with a node or a linear way (which still does 
not mean the polygon is a good data model for such features, just that it has 
in those cases - besides all disadvantages - also some advantages over a node 
or a linear way).

This situation was relatively stable - there were some attempts to suggest 
universally mapping bays with polygons rather than nodes previously:

https://lists.openstreetmap.org/pipermail/tagging/2014-October/thread.html#19775

which however never reached consensus because of the weighty arguments against 
this idea and because it was always clear that this would be a non-sustainable 
strategy for OSM in the long term.

Until early 2018 when OSM-Carto (where merging changes was at that time 
possible without consensus) added rendering of labels for bay polygons with 
label size and starting zoom level being determined by the size of the polygon 
but otherwise with no visual feedback or consideration for the geometry of the 
polygon:

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

- dismissing warnings about the counterproductive incentives this creates:

https://github.com/gravitystorm/openstreetmap-carto/issues/2068#issuecomment-191677580

This lead to a massive change in mapping activities with some mappers engaging 
in systematic endeavors of removing bay nodes and  drawing labeling polygons 
instead.  You can probably say this was by far the most successful attempt at 
steering mappers into a certain direction ever undertaken by OSM-Carto.  While 
the relative number of bay polygons compared to nodes only increased from about 
5 to 15 percent while very few bays were actually newly mapped the total 
surface area of bay polygons probably increased by a factor of 100-1000 - many 
of them evidently pure labeling geometries.  See

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

for some examples.  This has lead to some mappers removing such label geometry 
drawings as non-verifiable and pointless (like the mentioned Gulf of Bothnia) - 
though practically none of these attempts could make a dent against the massive 
labeling polygon drawing trends.

What does this have to do with technical limitations or constraints?  Very 
little.  Technical limitations and performance constraints in rendering have 
never been a factor speaking against drawing large and non-verifiable labeling 
polygons.  OSM-Carto and countless other map styles have for many years labeled 
huge administrative boundary relations without issues and this is not any more 
difficult for bay polygons.  And if it was an issue the solution would be 
rather simple:  Precalculating ST_PointOnSurface() on import in osm2pgsql.

The argument against drawing bay and strait polygons is one of practical 
verifiability and maintainability for the mapper.  This is not a technical 
issue, this is a social issue.  

Now i completely get the frustration of both mappers and map producers here.  
Mappers want their mapping to be shown in good quality in maps and if the only 
way to achieve that is to draw non-verifiable labeling geometries they are 
willing to invest significant time and energy into that and rationalize that in 
various ways.

And for map producers with a rudimentary GIS data analyst background and 
experience mostly in more or less atomic processing of point, linestring and 
polygon geometries and their spatial relationships but no deeper background in 
cartographic data processing specifically, the task of producing high quality 
labeling from bay nodes and a flat set of coastline ways or the osmcoastline 
output is a steep hurdle.  And in conventional digital map production from 
dedicated cartographic databases (in contrast to OSM with its generic 
geodatabase scope) labeling polygons is the state of the art to manage labeling 
of course.

The problem we have here is that of a widening gap between the goals and 
aspirations of the mapper community - 

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

2020-11-24 Thread 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 

 . 

 

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 
 :

>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  

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

2020-11-24 Thread 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

2020-11-24 Thread 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

2020-11-24 Thread 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

2020-11-24 Thread 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