Modify

Opened 10 months ago

Last modified 10 months ago

#16261 assigned enhancement

[PATCH] Implement check for buildings sharing nodes with res. area or ways.

Reported by: marxin Owned by: marxin
Priority: normal Milestone:
Component: Core validator Version:
Keywords: Cc: qeef

Description

Add new check for sharing of nodes. It's useful when doing validation for HOTOSM tasks.

Attachments (1)

0001-Implement-check-for-buildings-sharing-nodes-with-res.patch (4.8 KB) - added by anonymous 10 months ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 months ago by Don-vip

Why "Building sharing point with a building" should be a warning? It's perfectly valid and common.

comment:2 Changed 10 months ago by marxin

Owner: changed from team to marxin
Status: newassigned

comment:3 in reply to:  1 Changed 10 months ago by marxin

Replying to Don-vip:

Why "Building sharing point with a building" should be a warning? It's perfectly valid and common.

You are right that for many cities it's valid. But as mentioned, HOTOSM tasks very often handle low-developed areas where such pattern means in 99% of cases a mistake done by user. If you mind, I would disable the warning by default and HOTOSM validators will enable that on request.

comment:4 Changed 10 months ago by marxin

Cc: qeef added

comment:5 in reply to:  1 ; Changed 10 months ago by Klumbumbus

Replying to Don-vip:

Why "Building sharing point with a building" should be a warning? It's perfectly valid and common.

Yes, this test should not be in JOSM by default (even not as info level).

comment:6 in reply to:  5 ; Changed 10 months ago by marxin

Replying to Klumbumbus:

Replying to Don-vip:

Why "Building sharing point with a building" should be a warning? It's perfectly valid and common.

Yes, this test should not be in JOSM by default (even not as info level).

Agree. Will it be then acceptable with the change?

comment:7 in reply to:  6 ; Changed 10 months ago by Don-vip

Replying to marxin:

Agree. Will it be then acceptable with the change?

I'm not in favour of having something disabled in core for most of our users. You should rather implement this check as a mapCSS rule dedicated to HOTOSM, see examples in Rules

comment:8 Changed 10 months ago by Don-vip

Reporter: changed from anonymous to marxin

comment:9 in reply to:  7 Changed 10 months ago by Klumbumbus

Replying to Don-vip:

I'm not in favour of having something disabled in core for most of our users. You should rather implement this check as a mapCSS rule dedicated to HOTOSM, see examples in Rules

Yes, sounds better.

comment:10 Changed 10 months ago by marxin

I can confirm following mapcss patterns works for me. One exception is situation of 2 buildings that share a point:

  • data/validator/geometry.mapcss

    diff --git a/data/validator/geometry.mapcss b/data/validator/geometry.mapcss
    index 9dc1831b7..dac71416b 100644
    a b area:closed:areaStyle[landuse!=residential][tag("landuse") = parent_tag("landuse 
    189189  throwWarning: tr("Overlapping Identical Landuses");
    190190}
    191191
     192area:closed[building][building!=no] > node {
     193  set node_in_building;
     194}
     195
     196area:closed:areaStyle[landuse=residential][landuse] > node.node_in_building {
     197  throwWarning: tr("Building sharing point with a residential area");
     198}
     199
     200way[highway] > node.node_in_building {
     201  throwWarning: tr("Building sharing point with a highway");
     202}
     203
     204area:closed[building][building!=no] ⧉
     205area:closed[building][building!=no] {
     206  throwWarning: tr("Building sharing point with a building");
     207}
     208
    192209/* see ticket:#9522 */
    193210node[tag("amenity") = parent_tag("amenity")] ∈ *[amenity][amenity != parking] {
    194211  throwWarning: tr("{0} inside {1}", concat("amenity=", tag("amenity")), concat("amenity=", tag("amenity")));

Can you please help me how to do it for the buildings?
Thanks

Last edited 10 months ago by Klumbumbus (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned The owner will remain marxin.
as The resolution will be set.
to The owner will be changed from marxin to the specified user.
The owner will change to marxin
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.