Change rendering for natural=spring

[matkoniecz]

http://www.openstreetmap.org/?mlat=49.75063&mlon=19.79288#map=19/49.75063/19.79288

1) It looks like 5, not like S 2) I am unsure whatever S = Spring is obvious even for native speakers

I suggest some more obvious icon - maybe something like https://commons.wikimedia.org/wiki/File:RiverIcon-Spring.svg ?

Also orienteering maps have a good symbol for springs:

from http://www.maprunner.co.uk/simon/mapsymbols.jpg

[javbw]

That orienteering icon looks good. is there any documentation for what -carto needs for icons?

[matkoniecz]

According to #326 display of icon for node is completely independent from data about way where it belongs, so orienteering type icon that depends on where waterway goes may be impossible to implement.

[gravitystorm]

As a first stage it could be improved by just being a filled markersymbolizer.

The problem with rotating icons is coming up with a sufficiently complex SQL statement. It's possible to do this though.

[javbw]

If we have an omni-directional icon, or one always displayed vertically, we can still make one without using a letter. The USGS topo map symbols http://www.lib.utexas.edu/maps/usgs_ref/usgs5.jpg use a little round circle to indicate well, and and round circle with a tail to represent spring.

If we use a little fountain symbol (blue, water squirting up) to denote a spring, the stream way (if there is one) would take care of the directional part of it all .

Maybe something like this.

[javbw]

here is the old spring S with slightly rounded corners to look more like an S

[mrwojo]

This is a prototype for a directional query:

(select distinct on (p.way) p.*, degrees(ST_Azimuth(p.way, ST_PointN(l.way, 2))) as azimuth_degrees
    from planet_osm_point p
    join planet_osm_line l
    on ST_DWithin(p.way,l.way,0.1)
    where p."natural"='spring' and l.waterway='stream') as natural_spring

I'd go with an icon that doesn't need to be directional, because the above query is overkill with the waterway already providing a visible direction. I noticed that JOSM uses one icon for both springs and fountains.

[matthijsmelissen]

Example icon: http://osm-icons.org/images/c/c9/24021.svg

[xsuchy]

I would suggest http://miroslav.suchy.cz/osm/spring.png ! spring

I used to see this icon in our old maps and I very liked that. And it is very similar to what @javbw mentioned. It is created from from blue dot, which represent the spring itself, and the curve is made from letter S (as spring) and it is symbol of the water which flows from the spring.

[zdila]

Please use this icon http://goo.gl/ku7aWM

I am author of the icon and I am releasing it under public domain.

If you need any modification to that icon, feel free to do it or ask me to do it.

[pnorman]

The problem with rotating icons is coming up with a sufficiently complex SQL statement

Coming up with a sufficiently complex SQL statement is never a problem for me! :)

Please use this icon http://goo.gl/ku7aWM

I am author of the icon and I am releasing it under public domain.

If you need any modification to that icon, feel free to do it or ask me to do it.

How does that look rendered to 16x16?

[zdila]

I've uploaded new revision so that image fits to 16x16px page. Preview on green background:

[Klumbumbus]

I noticed that JOSM uses one icon for both springs and fountains.

JOSM-latest uses now different icons for spring and fountain. See https://josm.openstreetmap.de/ticket/10597

[nebulon42]

For nodes that are part of a waterway a simple circle would be sufficient. Like here: http://www.openstreetmap.org/#map=17/48.18177/16.24524

Detached springs would look weird, though:

While I like the icon of @zdila it does not look so good connected to a waterway if not rotated properly:

Or something like @javbw proposed?

Admittedly, this needs more work so that it doesn't look like a flower, but I like the last variant best so far.

We also have to make sure that the icon is different enough from fountains (see #705 for rendering request).

[kocio-pl]

It's quite clear that it's not a flower because it has a water color and is not symmetric. It's much better than current symbol, so I would be happy to replace it as soon as possible. I think I will also use your icon for the fountain, so there's no risk of confusing them.

[kocio-pl]

What about something like this on z14:

[kocio-pl]

Another draft, based on the Osmic fountain icon (IMO lack of symmetry doesn't work with fountain anyway) with marina-text color: z14 z19

[kocio-pl]

The same icon with lighter water-text color (#6699cc, also used for spring labels already) in park, without and with name label: z14 z19 z16 z19

And in the forest: z14 z16 z19

I would say the lighter version is better in general. We can try using halo around it, but I don't know how to do it - just adding:

    marker-line-color: #ffffff; 
    marker-line-width: 1;

is not working. Maybe the icon has to be prepared to show it?

[nebulon42]

IMO clearly better than what we have currently. Lighter is better but I think it is a bit too light for forest.

[kocio-pl]

Great! Do you like to make the color a bit darker or try a halo (in this case I need some instructions how to make it)?

[nebulon42]

marker-line-color and similar only work for arrow or ellipse marker types. You could either experiment with the color or try a halo. I still think that halos would be a good idea around all icons, but they were rejected for space reasons. So it might be strange if spring would be the only icon with one.

If you still want to try it, here is an example: https://github.com/gmgeo/osmic-josm-style/blob/master/icons/outdoor/fountain-18.svg Please note that the halo colour and opacity cannot be changed from within the stylesheet.

[xsuchy]

I do not like it. It looks like fountain to me. Spring is something which usually slowly flew from earth/rock. It usually does not spurt like that icon. So IMHO it is incorrect symbol.

[kocio-pl]

Could you at least describe, or better draw a draft yourself or show some already existing icons which would look the way you like it?

[imagico]

Here is a suggestion how spring could be rendered in a non-obstrusive way:

Note this is rendered below the water-lines layer which places it also below almost everything else. This is IMO correct since springs are hydrographic features and not POIs.

[kocio-pl]

I have no specific vision how should it look like. I just hate current "S" icon with passion (as much as I hated "Q" in a quarry pattern) and I'm perfectly happy with what I have just showed (10 px size, light blue), however I don't care if we like to use something else.

Latest proposition seems to be exactly what @matkoniecz has proposed - with proper "rotation" (clever hack, @imagico!) when the corresponding stream is attached. The question remains if we accept detached springs this time (it's the same problem as with the previous draft)?

If we're not really sure, the helper question could be if we think that all (or just most) of the springs should have the stream associated and treat detached ones as a temporary marks?

[daganzdaanda]

The rotated circle is very nice! I also think that they work OK without streams attached. It can be guessed that it is a water feature, it's probably maybe more intuitive than the "S".

Have you tried a white outline to fit with the stream casing? It might look good on forests but bad on meadows.

[polarbearing]

+1 for @imagico's circles.

[imagico]

Have you tried a white outline to fit with the stream casing?

On bright backgrounds this is going to look like a normal water area which is not distinct enough IMO. Relative weights of the dark outline and bright halo could of course be tuned but what i showed seems a reasonable choice also considering it should not be too much weaker than the current design.

The outlining by the way would also allow for specific rendering of variants in a subtle way (i.e. intermittent springs with dotted outline, hot springs with a reddish color).

[kocio-pl]

@imagico Do you plan to open PR with your proposed rendering? I would be happy to get rid of "S" and have reasonable spring icon at last.

[imagico]

This does not have high priority for me right now. If you or anyone else wants to try this it is fine with me. My demo uses SVGs which is not really a good approach probably regarding adjustability.

[vdmit]

@kocio-pl, your variant seems to be more contast and more readable. Voting for your icons.

[d1g]

It was suggested that natural=spring + drinking_water=yes objects should be rendered first. I somewhat support this idea.

[kocio-pl]

I'm not that fluent in Russian. =}

What do you mean? That a "drinkable" icon should be rendered instead of spring if both tags are on the same object? It's outside the scope of this issue, I guess.

[d1g]

I'm not that fluent in Russian. =}

alexkmbk commented that sometimes there only 5-10% drinkable/usable springs. He also noted that OsmAnd uses bigger icon for "drinkable" ones.

That a "drinkable" icon should be rendered instead of spring if both tags are on the same object?

I don't think this is best option for users. There many natural=spring, but not all of them are drinkable (usable). Some natural springs are not good landmarks (i.e. you will visit them only when you know their coords)

Simplest option is to make natural=spring + drinking_water=yes bigger than natural=spring; or to use shield with white background if they are tagged drinking_water=yes.

Alternately, you can render "natural=spring + drinking_water=yes" with full "S" letter, but "natural=spring" with only blue centered dot.

[kocio-pl]

Now I understand. We're stuck with new design for some time, but IMO it should be related to those propositions. If you want to make just a "temporary fix" for current icon, I guess you should file a new issue.

[Penegal]

To be sure: what does miss for this to be closed? A rendering for the blue circles?

[HolgerJeromin]

Right now we still have the non intuitive s for spring. So nothing has changed

[StyXman]

+1 to @imagico 's code, I wish he shares the code or at least a description how he did it, so we can reproduce easily without reverse engineering it from a render...

[imagico]

The samples were just a proof of concept, as explained using a simple SVG marker. There is nothing of substance to reverse engineer. The code is here:

https://github.com/imagico/openstreetmap-carto/tree/spring-icon

but i would be rather disappointed if this is just dumped into the style here without giving additional thought to both styling and implementation.

Personally i got to the conclusion that the styling demonstrated does not actually work that well in many situations and it would be a step back in terms of mapper feedback compared to the current one. The goal of constructive mapper feedback calls for clarity and definition in styling. Using the demonstrated design would communicate a rather vague definition of the concept of a spring which would over time likely have a negative effect on data quality (like blurring the definition into man_made=water_well and amenity=watering_place).

You should keep in mind that intuitive readability of the map is not a goal of this style per se, it is a means to achieve better legibility. Supporting mappers in correct tagging however is a goal. That means if you can achieve intuitiveness only in combination with vagueness and ambiguity this is not desirable regarding the documented goals of this style.

[Penegal]

@imagico: maybe your PoC was not the best solution, but it would at least be better than the current non-intuitive S icon. We could improve it later if we see it's relevant; on the other hand, waiting for the ideal solution could be waiting for ever, as there may as well be no better solution than the one you gave. This blue dot you designed is akin to what is used on, for example, French maps, and I've never heard anyone complaining it was unclear. The simple fact that it is a perfect circle which size isn't proportional to zoom should be enough to distinguish it from a water area.

Perfect is the enemy of good, I was always told, and that seems to fit for the situation.

[imagico]

We could improve it later if we see it's relevant

Perfect is the enemy of good

These are mantras many on this project subscribe to but as far as i can see no one ever produced a shred of evidence that these are actually principles supported by facts and not just dogmas established to justify mediocrity.

OTOH there is plenty of evidence that the opposite, that good enough is the enemy of great, is something that frequently happens in this style. The problem is ultimately also that only by striving for excellence you actually learn to distinguish between mediocrity and excellence.

And even if you subscribe to the above mantras you need to ask yourself if the reason why you do this is because you truly think this is a good strategy for improving the style or if this is due to the inability or unwillingness to do better. If the alternative for you is to wait for for the ideal solution that to me indicates the latter.

In other words: Striving for excellence is not only a strategy for developing a high quality style, it is also a strategy for developing the competence of its developers. People will only become excellent at their work if there is a minimum level of pressure to be excellent.

What you might also want to consider is that the change you are now arguing for was only developed because i did not accept the 'good enough' solutions suggested before and put some effort into creating something better. So you would in a way be accepting the fruits of a development strategy but still reject the strategy itself. I have no problem with that per se but it is kind of inconsequential.

By the way after three years of this issue being open still no one seems to have looked into developing the original idea by @matkoniecz...

[kocio-pl]

Perfect is the enemy of good

good enough is the enemy of great

For me it's mostly a false dichotomy. We have bad solution and "mediocre" now (I don't feel it's mediocre, I like it, but let's say). Why not deploy this mediocre and replace it with perfect once it's ready? What do we loose this way?

I guess waiting for better solution 4 years means that we agree on using bad solution all this time and that makes me feel uncomfortable.

[dieterdreist]

2018-02-14 15:09 GMT+01:00 kocio-pl notifications@github.com:

Why not deploy this mediocre and replace it with perfect once it's be ready? What do we loose this way?

admittedly, most people will not engange to improve a good but not perfect solution, but will do so if the pain level is sufficiently high ;-)

[kocio-pl]

Nobody is working to improve bad solution for years and nobody will work to improve perfect solution (by definition...). So even if nobody will work on medium solution, it's the same, but at least we have no bad solution then.

[Penegal]

Maybe I shouldn't have told about this perfection thing; it seems clear to me that it only added confusion to my post when I thought it could actually clarify it.

My question was much simpler than that: what isn't satisfying with the blue dots @imagico designed? It seems it is a readability question, but, as I told, I don't understand what the matter is: the simple fact that it is a perfect circle which size isn't proportional to zoom should be enough to distinguish it from a water area, if that is the anticipated problem.

Plus, it seems there is a consensus in favor of this rendering, if that matters.

[kocio-pl]

i would be rather disappointed if this is just dumped into the style here without giving additional thought to both styling and implementation.

It would be helpful to know what exactly do you consider to be a problem then.

For both man_made=water_well and amenity=watering_place it shouldn't be too hard to design an icon (see also #1224). For natural=spring it's hard to do it in unobtrusive way, as we have seen it above. It's also a question what would be the consequences if it's not perfectly clear what it is?

[imagico]

@Penegal - I explained above (in https://github.com/gravitystorm/openstreetmap-carto/issues/325#issuecomment-364646700) in detail why i think the demonstrated design is not a good idea for this style.

To give a specific example to this more abstract explanation: A mapper incorrectly tagging a water well as natural=spring would for example get positive feedback from the map about it since the rendering would be just as suited for man_made=water_well as it is for natural=spring despite these being two distinct and well defined features. This would be a step back from the current design (which might not be very intuitive but it is very distinct) and over time would blur the definition of natural=spring in the database.

As a map designer you might simply not care about this because you are fine with rendering springs, wells and other water related point features all in the same way but that would be very short sighted and incompatible with the documented goals of this style. Needless to say that many traditional maps - as you already pointed out - render springs in a distinct form and they specifically render springs and not springs, wells and other water related point features.

Regarding perfection - it is important to realize that pursuit of excellence and greatness is not the same as being perfectionist. It is about having high standards, critically evaluating your own work and not being satisfied by marginally meeting minimum requirements.

Plus, it seems there is a consensus in favor of this rendering, if that matters.

Consensus is not required here. I am presenting my reasoning here for others to possibly learn from it or to argue my points (which might allow both of us to learn something).

[Penegal]

OK, thanks for the explanation; I lacked some understanding of your last answer, now I feel it clear.

Another possibility: render springs as a blue ring, with only transparency inside, below the waterway layer. Such rings could be drawed with a darker shade of blue, to highlight their difference with water areas. This way:

• being filled with nothing, confusing it with something else as wells or water areas would be harder, and that would highlight their punctual nature (they would be empty, as one cannot fill a point, only an area),
• being below the waterway layer, they would be hidden by the outgoing waterway, which would make them opened on the waterway side, which is what @matkoniecz suggested first; this way, it would clearly show that they are filling the waterway with water, as they will look like an opening from where the waterway would emerge,
• if relevant, a different colour would highlight, again, that it is not a well or an area, but something clearly different.

Some examples from French maps:

I find it difficult to confuse these with wells: I would assume circles representing wells to be filled with black, as they are in reality.

P.-S.: here, in France, springs and water wells are displayed the same, with only a label saying Source or Sce for springs, and Puits or Pts for water wells; that could explain why highlighting the difference between them using the symbol was not as important to me as it is to you: it never has been a real issue to me until now, as the label told me the difference. But I see now that these labels uselessly clutter the map where a different symbol could make it, and are not applicable to the multiscript, multilingual nature of OSM, so it does no more seem a good idea, which brings us back to the starting point: telling the difference with symbols.

Edit:

I am presenting my reasoning here for others to possibly learn from it or to argue my points (which might allow both of us to learn something).

Oh, I would like to see everybody doing that in debates, instead of letting their ego speak – I'm not saying this for the current topic, but for everyday debates..

[kocio-pl]

It makes sense for me - dropping the fill will make it more abstract, while not being cryptic, language specific symbol as currently.

Additional note: context is always important, not only the graphic design. Properly mapped area will include stream flowing out of the spring. Cases like this:

are most probably just not finished. Maybe there are sources that don't have the visible stream flowing out, but they should be rare (does anybody know such places?). For example here the missing stream has been added eventually, along with many other objects:

Also the wells should generally be placed near some populated places, not in the middle of nowhere, where springs can be found. It's not a hard rule, but looking at the image above I don't think of wells or watering places, even without the streams attached.

[Penegal]

An example of @imagico's test without the blue fill:

At first, I thought of increasing the ring's thickness, but it may be voluntarily thin. What do you think?

[kocio-pl]

Hard to notice spring without the stream here (only the name helps). I would rather use the same color as stream, so it could be closer to original @matkoniecz design.