Segmented roads lead to too high or too low density of shields and names

[matkoniecz]

http://www.openstreetmap.org/?mlat=50.0899&mlon=19.9113#map=14/50.0910/19.9144 http://www.openstreetmap.org/?mlat=50.0899&mlon=19.9113#map=15/50.0899/19.9113

http://www.openstreetmap.org/?mlat=50.08948&mlon=19.90827#map=18/50.08948/19.90827

Similar to #673 (but with reversed problem) and may be also unfixable.

[gravitystorm]

It's fixable - we can change the SQL to join up linestrings that have identical references and highway types. As to whether that's too much pre-processing, I think it would be OK for this instance.

Of course, there's a question then around shield spacing (gap when repeating on one line) and shield min distance (gap between any shields) since it appears from this we need to adjust min-distance to be similar to spacing, perhaps? Certainly the first picture has them far too close together.

[Newbie07]

+1

We still have the opposite problem, as-well. A long way which gets to few shields. A similar issue happens with names on streets.

We need some solution to get nice results on both sides of the scale.

[matkoniecz]

@gravitystorm

It's fixable - we can change the SQL to join up linestrings that have identical references and highway types. As to whether that's too much pre-processing, I think it would be OK for this instance.

It seems that this method may be used to fix #673

[pnorman]

It's fixable - we can change the SQL to join up linestrings that have identical references and highway types. As to whether that's too much pre-processing, I think it would be OK for this instance.

Unfortunately it has negative impacts for shields at MT edges. We could fix this, if 2.3.0 was released and we bumped our dependency and we used avoid-edges. (https://github.com/gravitystorm/openstreetmap-carto/pull/203#issuecomment-53028842), but that's not an option yet. I think we need to increase min distance, and if that doesn't fix it, look at merging.

My understanding is performant merging in SQL is not trivial either.

[gravitystorm]

@pnorman or we can always clip the merged linestrings to a negatively-padded !bbox! :-)

[pnorman]

@pnorman or we can always clip the merged linestrings to a negatively-padded !bbox! :-)

Ya, but we don't know the padding in the SQL, so we don't know how much to de-pad. e.g. when rendering in TM1 we have a total render size of 768px, of which 256px is padding. In production we have a total render size of 2304 of which 256px is padding. If deployed to the osm.fr servers, it's 2560 of which 512px is padding.

Merging is hard for inter-tile effects.

Rendering from relations only would solve some problems, as those are longer linestrings (100 mercator km), but we can't do that, even aside from the areas that don't use route relations - we colour based on highway tag, so the shield needed can change throughout a relation.

[jeisenbe]

Looking at the discussion above, it seems we can now use avoid-edges to prevent some of the problems that would be found with pre-processing roads into linestrings per metatile, because we already require Mapnik 3.0.

Does anyone know how to "change the SQL to join up linestrings that have identical references and highway types" and want to give it a try?

We will need to see how much of an impact on performance is experienced.

[kennykb]

I have proof of concept code for the SQL (which, alas, depends on the slim tables because it makes linestrings from route relations) at https://github.com/kennykb/osm-shields. I don't think it would be an inordinate amount of effort to prune down the 'analyze_markers' function ( https://github.com/kennykb/osm-shields/blob/master/queryprocs.sql.in#L190) to do what you want. The pathway for roads that aren't in route relations - which is what you want if we continue to ignore the issues with route concurrency - starts at https://github.com/kennykb/osm-shields/blob/master/queryprocs.sql.in#L398. The key call to defragment the contiguous roads is the ST_LineMerge call at https://github.com/kennykb/osm-shields/blob/master/queryprocs.sql.in#L417 .

Let me know if I can help!

On Thu, Nov 7, 2019 at 2:24 AM Joseph E notifications@github.com wrote:

Looking at the discussion above, it seems we can now use avoid-edges to prevent some of the problems that would be found with pre-processing roads into linestrings per metatile, because we already require Mapnik 3.0.

Does anyone know how to "change the SQL to join up linestrings that have identical references and highway types" and want to give it a try?

We will need to see how much of an impact on performance is experienced.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/951?email_source=notifications&email_token=AABU6UNPYEGFCIP6F6RAS7TQSPGFBA5CNFSM4AUHZJQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDLTIZY#issuecomment-550974567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABU6UOJHC6GLGVJD5EJVITQSPGFBANCNFSM4AUHZJQQ .

-- 73 de ke9tv/2, Kevin

[polarbearing]

497 Improve rendering of street names

[jeisenbe]

Does anyone want to submit a PR which shows a feasible method for solving this issue?

[maro-21]

Actual behavior

The name of a street is not displayed if the street is in small pieces.

Expected behavior

Display street names regardless split street. If connected ways have the same name, treat them as one feature and display the name.

Links and screenshots illustrating the problem

Example 1: https://www.openstreetmap.org/way/190721339

This roundabout had to be split due to bus routes, so if it was in one piece, it would probably be rendered correctly.

But it's a general issue with street names, not only roundabouts.

Example 2: 327856867 + 312911913 + 312911914 + 22769131

This is one street in four pieces but had to be split because of different tags. There is enough space for the street name so it should be rendered.

[matkoniecz]

Note that this issue is already reported, there is no need to repeat the report.

Current blocker is "nobody wrote a code solving this issue", not "nobody is aware about this problem".

[maro-21]

It's been "reported" for 6 years now... I've just added my examples.