False validator warning on ford if node is outside the downloaded area and highway or waterway is not loaded

[mdk]

If you download an area with a highway=* or waterway=* and this way contains a node outside the downloaded area with ford=yes and the intersecting way of the other type type is not really missing, but just not downloaded yet, the validator will show false warning: "ford should be on the node where highway and waterway intersect". It's hard to find the real problems this way.

Example: download the way 293437015 and run validator.

Only nodes inside the downloaded area should be checked.

[simon04]

Do we have a naming convention for MapCSS pseudo classes (and functions)? It seems that mostly lower_case_under_score is in use.

[bastiK]

It is indeed not very consistent at the moment:

right-hand traffic -> :righthandtraffic (no separator, no camel case)
same tags -> :sameTags (camel case)
unclosed multipolygon -> :unclosed_multipolygon (underscore)

When clinging to ​CSS, i guess the correct would be dashes:
first child -> :first-child

My vote is for dash or underscore.

In any case, function names should keep the underscore as it is hard to distinguish between identifier-dash and minus in an expression.

[skyper]

See #11261 for the general underlying problem.

[simon04]

In 8494/josm:

see #11150 - MapCSS: refactor pseudo classes to factory based instantiation; consider :sameTags, :same-tags, :same_tags equivalent

[simon04]

In 8495/josm:

fix #11150 - False validator warning on ford if node is outside the downloaded area and highway or waterway is not loaded

[aceman]

There is the same problem also for the "link not connected to the proper class road" warning. The general solution could either be #9572 or do not run the affected class of validations on nodes/way outside of the downloaded area.

[bartosomail@…]

I can still replicate the false validator warning on ford if node is outside the downloaded area and highway or waterway is not loaded:

1) I select an highway which ends outside the downloaded area;
2) I apply the "Way Download" (Ctrl+Shift+W) to download an adjacent section of highway (completely outside the downloaded area) and containing "ford" nodes; at this time, the validator still doesn't list the ford warning;
3) I select this just downloaded highway and apply again "Way Download" to download the next segment (completely outside the downloaded area); now validator lists the ford warnings.

[Klumbumbus]

Replying to bartosomail@…:

I can still replicate the false validator warning

Can you please attach a sample file?

[Klumbumbus]

Replying to simon04:

In 8495/josm:

fix #11150 - False validator warning on ford if node is outside the downloaded area and highway or waterway is not loaded

The pseudo class does not update if you move a node out of or into the downloaded area. There is the same problem also for :righthandtraffic (maybe the same bug).

[mdk]

Replying to Klumbumbus:

The pseudo class does not update if you move a node out of or into the downloaded area. There is the same problem also for :righthandtraffic (maybe the same bug).

Moving nodes from outside into the downloaded area are extreamly dangerous operations. JOSM estimates the "all dependencies are downloaded" only by the position of the node at the moment of the check. When you move a node (which is also a member of a not yet loaded way) from outside into the downloaded area and delete this node, you get no warning, that the not loaded way lost a node.
I didn't try to upload such inkonsistent data, but eighter upload will fail or the second way contains a deleted node!

I describe this problem also in #11198 and outline in comment 11 a sustainable and lean solution for all problems relatet with not compleatly loada objects.

[anonymous]

Replying to Klumbumbus:

Replying to bartosomail@…:

I can still replicate the false validator warning

Can you please attach a sample file?

I attached the sample file ford_warning.osm

[Don-vip]

Milestone renamed

[simon04]

Postpone enhancements to next release.

[Don-vip]

In 9021/josm:

fix #11150 - fix wrong bounds computation for multiple data sources in .osm file