Betrachte 13 Beiträge - 1 bis 13 (von insgesamt 13)
  • Autor
    Beiträge
  • #44033
    ede123
    Teilnehmer

    Hallo zusammen,

    lese hier schon eine weile und konnte bisher immer eine Antwort finden, aber hier habe ich scheinbar die falschen Suchbegriffe:

    Mir ist kürzlich ein merkwürdiger „schwarzer Balken“ im Kartenrendering von Oruxmaps aufgefallen, d.h. ein Kartenbereich der nicht richtig gerendert wird.

    Die absolute Größe des nicht gerenderten Bereichs ist nicht konstant ändert seine relative Größe mit der Zoomstufe (d.h. bei kleiner Zoomstufe ist der ganze Bildschirm schwarz, bei sehr großer Zoomstufe wird der Balken sehr schmal. Ganz verschwindet er jedoch nie (was natürlich extrem störend ist, wenn man in der Region unterwegs ist…).

    Die Linke obere Ecke ist fix und scheint irgendwo in der Region Aßling in Bayern zentriert zu sein falls das irgendwie hilft.

    Was ich schon probiert habe:

    • Kartenupdate -> Aktuellste Karte zeigt gleiches verhalten
    • Unterschiedliche Kartenausschnitte (Alps, Alps East, Germany South) -> zeigen alle das gleiche Verhalten

    Was ich noch nicht ausgeschlossen habe sind die DEM files. Ich verwende hier die 3″ Version von http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm als Relief-Überlagerung.

    Ich habe euch mal zwei Screenshots als Beispiel angehängt. Irgendeine Idee woran das liegen könnte?

    #44038
    ede123
    Teilnehmer

    Manchmal muss man es aussprechen um auf die richtige Spur zu kommen:
    Wenn ich die Geländeschattierung deaktiviere, verschwindet der Balken!

    Die Geländeschattierung verschwinded offensichtlich aber auch, aber die würde ich natürlich gerne behalten. Irgendeine Idee was da falsch läuft?

    #44039
    ede123
    Teilnehmer

    Und jetzt habe ich sogar jemanden mit dem gleichen Problem gefunden: https://www.openandromaps.org/oam-forums/topic/schwarze-bloecke-in-germany-karte-mit-oruxmaps

    #44042
    @afgb1977
    Teilnehmer

    Hallo.
    Es ist ein kleines Problem im Zusammenhang mit den Profilen in OruxMaps.
    Erstellen Sie ein neues Profil von Grund auf.
    Ich weiß nicht wirklich, was passiert oder wie sich das von mir konfigurierte Profil auf das Rendern der Karte auswirkt, aber sobald die Profile gelöscht und ein neues erstellt wird, verschwindet das Problem.
    Der Fehler wurde vor einigen Tagen in der Telegram-Gruppe für OruxMaps entdeckt.

    Felipe

    @afgb1977

    #44043
    ede123
    Teilnehmer

    Danke für die Antwort!

    Leider gleiches Ergebnis:

    • Neues Profil aus Werkseinstellungen erstellt
    • Profil geladen
    • -> Problem zuerst weg
    • Geländeschattirerung aktiviert
    • -> Problem wieder da
    #44068
    ede123
    Teilnehmer

    Ich habe das Problem auch mal „upstream“ berichtet: https://oruxmaps.org/forum/index.php?topic=39980.0

    #44091
    @afgb1977
    Teilnehmer

    Nach mehreren Tests wurde die mögliche Ursache des Fehlers der schwarzen Quadrate gefunden.
    In der Telegram-Gruppe OruxMaps berichteten mehrere Benutzer über das gleiche Problem, nachdem sie die Karten basierend auf DEM (Hänge, Schatten und Relief) erschienen schwarze Balken. Sie sind mit einigen .hgt 1 „-Dateien von Sonny verknüpft.
    Durch die Änderung in NASAs .hgt 1 “ verschwanden sowohl die schwarzen Streifen als auch die Balken oder Streifen.
    Als ich die .hgt 1″ Sonny wieder benutzte, traten die Flecken wieder auf.
    Es wird empfohlen:
    Deaktivieren Sie die Schattierung für MapsForge oder tauschen Sie die .hgt-Dateien gegen andere aus, während Sie die Dateien reparieren oder ersetzt werden.
    Prüfungen:
    Sonny .hgt 1″ N37W06

    Felipe

    @afgb1977

    #44092
    @afgb1977
    Teilnehmer

    In the Telegram group OruxMaps the same errors have been reported by different users.
    After several tests it was detected:
    1. The error is directly related to the DEM .hgt files, maybe corrupt files or information gaps.
    2. These errors were found among .hgt users 1″ Sonny and ViewfinderPanoramas 3 „.
    3. When changing the file to NASA’s .hgt the error disappears.
    It is recommended to change the files on the affected grid while they are being updated, repaired, or upgraded.
    File and test area:
    N37W006 .hgt 1“ Sonny.

    Felipe

    @afgb1977

    #44109
    @afgb1977
    Teilnehmer

    The following is what we have identified regarding the error of the black squares and bars in OruxMaps, these being alien to the Maps or RenderThemes of OAM.
    In summary:
    – The error is generated by .hgt files with missing or corrupt heights info. (Many times they have info gaps or were not created correctly).
    – The .hgt that have problems are those of the OruxMaps server (ViewfinderPanoramas) and Sonny.
    – NASA .hgt do not present these errors at the moment.
    – The error becomes evident when activating the MapsForge Shading (there are 2 types of shading, one that acts on MapsForge and a general shading that acts on any map).
    – The easiest way to identify the error is to activate and view one of the maps generated by the DEMs.
    – The error disappears when the corrupt or damaged .hgt file is changed.
    – The error may originate from a common source which is the .hgt from ViewFinderPanoramas or data SRTM (those from the OruxMaps server and which are also used by Sonny to fill in spaces or gaps where there is no Lidar information).
    – The .hgt files with errors, empty or corrupted already existed before so there is something new in the OruxMaps updates that is not compatible with these corrupted files as the error becomes so evident.

    @afgb1977

    #44110
    @afgb1977
    Teilnehmer

    This message is to make a correction regarding what was published by me in the 3 previous messages.
    After several tests in OruxMaps it was concluded that the .hgt DEMs are not the source of the problem.
    Individual tests were done with .hgt Sonny (I apologized for suggesting that these files had information gaps and that this caused the black boxes). When doing the tests and not using a grid and not checking the coordinates, I assumed that the black squares were part of the coverage area of ​​the .hgt.
    I added more .hgt files (both Sonny 1 „and NASA 1“ in individual tests) to a test area and it was found that the black boxes were moving towards the extremes of the .hgt coverage.
    This indicates that it is not an error in the .hgt files, but it is a problem with OruxMaps to make the splice between the covered area and the area not covered by the DEMs.
    One of the workarounds is to not activate Shading while the developer makes the necessary corrections.
    I apologize again for suggesting the source of the error in Sonny’s .hgt.

    @afgb1977

    1 Teilnehmer(n) gefällt dieser Beitrag
    #44113
    ede123
    Teilnehmer

    Thanks for the correction!

    This certainly matches my personal observations (as mentioned in https://oruxmaps.org/forum/index.php?topic=39980.0 the artifacts became visible at the border between a tile that had DEM coverage and a tile where no .hgt was available, so possibly an interpolation issue or similar).

    Does the developer already have an idea what changed, i.e. is there a chance to see a fix soon?

    #44125
    @afgb1977
    Teilnehmer

    Hello.
    The developer is aware of the problem from reports made by you and other users.
    Apparently the error is associated with „some new libraries not working well“.
    An update will be released soon to fix this bug and others.

    @afgb1977

    1 Teilnehmer(n) gefällt dieser Beitrag
    #44127
    ede123
    Teilnehmer

    Great news! ?

Betrachte 13 Beiträge - 1 bis 13 (von insgesamt 13)
  • Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.