osm-parking-processing icon indicating copy to clipboard operation
osm-parking-processing copied to clipboard

Collection of information the debug layer should show

Open SupaplexOSM opened this issue 3 years ago • 7 comments

Hier der Beginn einer Liste von Dingen, die der Debug-Layer anzeigen könnte/sollte:

"Stanzflächen" und interpolierte Datenpunkte

  • [x] Stanzflächen aller Art (Einfahrten, Bushaltestellen, Fahrradständer etc.)
  • [x] Bordsteinschnittpunkte im Kreuzungsbereich
  • [ ] virtuelle Bordsteinkanten(?)

Fehlende Daten

  • [ ] Straßensegmente mit fehlenden Parkstreifeninformationen auf beiden (auffälliger) oder auf einer Seite (weniger auffällig)
  • [ ] Straßensegmente ohne position (unauffällig)
  • [ ] Straßensegmente ohne conditions (unauffällig)

Mapping-Fehler oder -Widersprüche

  • [ ] parking:lane:both + parking:lane:left/right
  • [ ] parking:lane:<side>/parking:condition:<side> am highway und gleichzeitig separate Flächen vorhanden (durch geometrische Überlagerung prüfen)
  • [ ] Tags nach altem Schema (insbesondere parking:lane:<side>=no_parking/no_stopping, parking:condition:<side>:default, parking:condition:<side>:time_interval)
  • [ ] parking:lane:<side> enthält ein "@"-Zeichen (dafür parking:lane:<side>:conditional verwenden)
  • [ ] service=parking_aisle + parking:lane:<side> (meist entweder doppelte Informationen, weil auf Parkplatzflächen liegend oder Fehlanwendung des parking_aisle-Tags)

SupaplexOSM avatar Aug 02 '22 20:08 SupaplexOSM

Für die Anzeige gegenüber Nutzern würde ich die Daten gerne in separierten Darstellungen präsentieren.

  • "Subtraktives Modell" verstehen / Stanzungen verstehen: Nutzer sollen sehen können, das das Script intern tut um entsprechend entscheiden zu können, wo noch (anders) gemappt werden muss.
  • "Datenfehler": Nutzer dort hin lenken, wo wir bestehende Daten als falsch ansehen, damit sie nach unserem Verständnis angepasst werden können (wenn zutreffend…).
  • "Vervollständigung": Nutzer dort hin lenken, wo aus unserer Sicht Daten fehlen, damit sie ergänzt werden können.

Lasst uns das ruhig gemeinsam sammeln, weil der Vector Tile Layer vielleicht später übergreifend ist; aber in der Nutzer-Ansicht würde ich es dann trennen wollen.

tordans avatar Aug 03 '22 04:08 tordans

  • [ ] parking=street_side ohne Auftrennung der Seiten (Beispiel)

gislars avatar Aug 03 '22 09:08 gislars

  • [ ] parking:condition:right ohne parking:lane:right
  • [ ] parking:condition:left ohne parking:lane:left
  • [ ] parking:condition:both ohne parking:lane:both
  • [ ] parking:condition, da ohne seitenangabe

joshinils avatar Aug 11 '22 03:08 joshinils

wäre es möglich eine definition per validator.mapcss datei zu schreiben was in das debug layer soll? da kann man auch differenzeiren, ob es fehler oder eine warnung sein soll, plus gründe und beschreibungen wie man das beheben kann.

im endeffekt also einmal eine validator datei aus josm für ganz berlin laufen lassen, und die ergebnisse dann in einer karte darstellen.

der vorteil wäre, dass man dieselbe validator datei in josm vor dem hochladen laufen lassen kann, und man sich somit sicher ist, dass man selber keine fehler hinzufügt.

joshinils avatar Aug 11 '22 04:08 joshinils

wäre es möglich eine definition per validator.mapcss datei zu schreiben was in das debug layer soll?

Die Styles müssen im Format der Style Specification für Layer definiert werden.

  • Docs https://maplibre.org/maplibre-gl-js-docs/style-spec/layers/
  • Beispiel https://github.com/tordans/parkraum.osm-verkehrswende.org/blob/main/project-vector-tiles/index.html#L61-L158 (Code wird später verschoben)

tordans avatar Aug 11 '22 05:08 tordans

verstehe, schade.

es ist möglich die ergebnisse des validators aus josm als xml datei zu speichern:

<?xml version='1.0' encoding='UTF-8'?>
<analysers generator='JOSM' timestamp='2022-08-11T05:28:32.960620125Z'>
  <analyser timestamp='2022-08-11T05:28:32.960620125Z' name='Tag checker (MapCSS based)'>
    <class id='1' level='2'>
      <classtext lang='en' title='missing tag &quot;is_sidepath=yes|no&quot;' />
    </class>
    <error class='1'>
      <location lat='52.64207807018' lon='13.28345676063' />
      <way id='-103224' visible='true'>
        <nd ref='-137732' />
        <nd ref='-137734' />
        <tag k='highway' v='footway' />
      </way>
      <text lang='en' value='null' />
      <fixes></fixes>
    </error>
  </analyser>
</analysers>

ist ein beispiel ohne echte osm-daten von einer eigenen validator regel.

joshinils avatar Aug 11 '22 05:08 joshinils

mit josm kann man auch den validator allein laufen lassen: josm validate -i test_validate.osm -i Documents/JOSM-Auto-Complete-Preset_joshinils/berlin-check.validator.mapcss -o test_validate.geojson ergebnis test_validate.geojson:

{ "type": "FeatureCollection", "features": [{ "type": "Feature", "properties": { "footway": "sidewalk", "@id": "way/-103258", "message": "missing tag", "description": "footway without highway", "code": 3000, "fixable": false, "severity": "Warnings", "severityInteger": 2, "test": "Tag checker (MapCSS based)" }, "geometry": { "type": "LineString", "coordinates": [
                [13.23619792526, 52.63190730079],
                [13.33013602008, 52.63308900297]
            ] } }] }

ich bekomm es aber leider nicht hin damit meine validator regeln anzuwenden. nur diese regeln selber auf fehler zu prüfen (was auch irgendwo toll ist, aber nicht hilfreich)

joshinils avatar Aug 11 '22 05:08 joshinils