BaseZoomLevels and NAME-Tag

54 views
Skip to first unread message

Christian Kernbeis

unread,
Aug 13, 2016, 6:09:30 AM8/13/16
to mapsforge-dev
Hi,

I'm on the wa to include waymark-symbols (OSMC:SYMBOL) in the OpenAndroMaps
The process of inheriting the tag from relations to the ways, splitting in seperarte tags (...) and prozessing seperate objekts for each waymark is straight forward - no problem.

An object for a waymark looks like:

    <node id="9940000000" lat="##.0571062" lon="-##.3277732" version="1" timestamp="1970-01-01T00:59:59Z" changeset="1">
       
<tag k="osmc" v="osmc_yes"/>
       
<tag k="osmc_nw" v="wmnw_rwn"/>
       
<tag k="osmc_color" v="wmco_yellow"/>
       
<tag k="osmc_background" v="wmbg_white"/>
       
<tag k="osmc_foreground" v="wmfg_yellow_lower"/>
   
</node>

Zoom-appear for _all_ tags is set to 13 = in the highest base.zoom.level
Although we are talking about 235.000 of these nodes in the Alps.map everything works absolut fine with included waymarks.

.. as long as I don't include a NAME tag. Doing this maps render with white tiles in Cruiser from the second base.zoom.level on = too much objects in my experience.
The name tag, in my implementation of the osmc:symbols, contains the :TEXT: portion of the osmc:symbol tag and is IMO essential for the waymarks.

For me it looks like that the name tag is stored globally regardless of the zoom-appears of the tags included in the object (node) ?
And pulls down the rest of the tags internally to lower base.zoom.level ?
Any way to solve this issue for an ordinaryy user of mapsforg as I am (and not a programmer)....

Base.zoom.levels are default mapsforge for the map in question.

Best regards
Christian

Emux

unread,
Aug 13, 2016, 6:37:33 AM8/13/16
to mapsfo...@googlegroups.com
Hi Christian,

Can you provide a sample map to check its behavior?

Or can you run cruiser.jar via command line and post possible exceptions in the log?
java -Xmx1024M -jar cruiser.jar

Objects with their attributes should normally be included in the sub-files i.e. zoom-intervals defined by the zoom-appear. In your case that is the 3rd highest detail one.

--
Emux

Christian Kernbeis

unread,
Aug 13, 2016, 1:00:01 PM8/13/16
to mapsforge-dev
Hi Emux,

Thanks for support, I will sort out this over the weekend and report.
Maybe the NAME-Tag is not the problem as name-tag, maybe its just a tag too much - I will try in parallel to create only real necessary osmc-nodes (maybe according to the amount of way-nodes in underlaying hiking ways or something like this) to reduce the overall footprint of the osmc:symbols.

/*

Objects with their attributes should normally be included in the sub-files i.e. zoom-intervals defined by the zoom-appear. In your case that is the 3rd highest detail one
*/
Thats why I'm creating seperate objects for the osmc_symbols, including these tags in the hiking way results in real massive problems (white tiles) cause the network tag (zoom-appear 7) pulls all other tags (zoom appear in 3rd base-level) to the 2nd base level. (thats my experience over the last years). I had these problems with my andromaps_### themes where I dont use zoom-min > these themes (in beginning) were only driven by the zoom-appear of the tag-mapping. If a tag was set in tagmapping and rendered eg in Level 10 (building=industrial) with a camp-site symbol in the same object set at zoom-appear 15 both objects were rendered at level 10.

Best regards
Christian

Christian Kernbeis

unread,
Aug 13, 2016, 2:35:02 PM8/13/16
to mapsforge-dev
Here is first log:

m:\atlas>java -Xmx1024M -jar cruiser.jar > log.txt
Aug 13, 2016 8:06:54 PM org.mapsforge.map.reader.MapFile processWayDataBlock
WARNING
: invalid number of way nodes: 0
Aug 13, 2016 8:06:54 PM org.mapsforge.map.reader.MapFile processWays
WARNING
: invalid way tag ID: 16409
Aug 13, 2016 8:06:55 PM org.mapsforge.map.reader.MapFile processBlocks
SEVERE
: 41802
java
.lang.ArrayIndexOutOfBoundsException: 41802
        at org
.mapsforge.map.reader.ReadBuffer.readSignedInt(SourceFile:145)
        at org
.mapsforge.map.reader.MapFile.decodeWayNodesSingleDelta(SourceFile
:355)
        at org
.mapsforge.map.reader.MapFile.processWayDataBlock(SourceFile:681)
        at org
.mapsforge.map.reader.MapFile.processWays(SourceFile:782)
        at org
.mapsforge.map.reader.MapFile.processBlock(SourceFile:451)
        at org
.mapsforge.map.reader.MapFile.processBlocks(SourceFile:559)
        at org
.mapsforge.map.reader.MapFile.readMapData(SourceFile:854)
        at org
.mapsforge.map.reader.MapFile.readMapData(SourceFile:829)
        at org
.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(SourceFi
le
:90)
        at org
.mapsforge.map.layer.renderer.MapWorkerPool$MapWorker.run(SourceFi
le
:155)
        at java
.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java
.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java
.lang.Thread.run(Unknown Source)

Aug 13, 2016 8:06:55 PM org.mapsforge.map.reader.MapFile processBlocks
SEVERE
: 41802
java
.lang.ArrayIndexOutOfBoundsException: 41802
        at org
.mapsforge.map.reader.ReadBuffer.readSignedInt(SourceFile:145)
        at org
.mapsforge.map.reader.MapFile.decodeWayNodesSingleDelta(SourceFile
:355)
        at org
.mapsforge.map.reader.MapFile.processWayDataBlock(SourceFile:681)
        at org
.mapsforge.map.reader.MapFile.processWays(SourceFile:782)
        at org
.mapsforge.map.reader.MapFile.processBlock(SourceFile:451)
        at org
.mapsforge.map.reader.MapFile.processBlocks(SourceFile:559)
        at org
.mapsforge.map.reader.MapFile.readMapData(SourceFile:854)
        at org
.mapsforge.map.reader.MapFile.readMapData(SourceFile:829)
        at org
.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(SourceFi
le
:90)
        at org
.mapsforge.map.layer.renderer.MapWorkerPool$MapWorker.run(SourceFi
le
:155)
        at java
.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java
.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java
.lang.Thread.run(Unknown Source)

Well, seems to be a simple overflow.
However - no information in which base.zoom.level so not very enlighting.
Maybe you could take a look at the source code whats happening there - if you have resources left for this.

Thanks
Christian





Emux

unread,
Aug 13, 2016, 2:47:21 PM8/13/16
to mapsfo...@googlegroups.com
On 13/08/2016 09:35 μμ, Christian Kernbeis wrote:
However - no information in which base.zoom.level so not very enlighting.

When the exception appears at what zoom you are?

--
Emux

Christian Kernbeis

unread,
Aug 13, 2016, 3:48:00 PM8/13/16
to mapsforge-dev
Sorry. cant reproduce this crash.
However, it was at a zoom-level higher than 12

I too have warnings about invalid latitudes (-90.718...) every time I a "white" tile is shown on screen - but I cant find any object in the OSM-File with these lat's.

Best regards
Christian

Emux

unread,
Aug 13, 2016, 3:50:09 PM8/13/16
to mapsfo...@googlegroups.com
You're using the latest master map-writer?

Also can you share a sample map file when this issue can be reproduced?

--
Emux

Emux

unread,
Aug 15, 2016, 2:11:48 PM8/15/16
to mapsfo...@googlegroups.com
You should definitely try latest master map-writer.

It has many improvements / fixes, like for the "invalid number of way nodes".
See https://github.com/mapsforge/mapsforge/issues/645.

--
Emux

Christian Kernbeis

unread,
Aug 18, 2016, 2:44:16 AM8/18/16
to mapsforge-dev
Hi Emux

I switched to the latest mapwriter, added some rules for basic the cleanup for OSM-Files (more detailed strip of stupid chars, aso..), more strict prozessing of the osmc:symbol, reduced the amount of symbols to 1 out of 2,...
Now it seems to work even fo big maps.
Alps and Austria render fine even with with :text: + :textcolor: +  prozessed textlenght (width of symbols) portion of osmc:symbol
Whats not working: Transfering the osmc:symbol color tag to the networks (iwn/nwn appear at level 7) results in white tiles - but thats no problem > OAM use its own color scheme for iwn/nwn/rwn/lwn.

Thanks again for all your efforts
Christian

Emux

unread,
Aug 18, 2016, 2:50:58 AM8/18/16
to mapsfo...@googlegroups.com
Thanks for the feedback Christian.

Please report any other findings you may have.

--
Emux
Reply all
Reply to author
Forward
0 new messages