Hi I've across something interesting when plotting boundaries. It appears that boundary=administrative [0x1c resolution 24] gets plotted 2x ie I examined the subfile and noticed 2 identical bitstreams at different offsets, within the same subfile. Only the lbl pointers are different. I wonder if this doubling is necessary as it increases the img file? Regards Nick -- View this message in context: http://gis.19327.n5.nabble.com/multiple-boundary-lines-tp5817950.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick, I saw this for boundary lines which are e.g. rivers. If you render the river and the boundary line, you'll have two similar objects with different types. Would that explain it? Gerd
Date: Sat, 20 Sep 2014 01:55:26 -0700 From: osm@pinns.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] multiple boundary lines
Hi I've across something interesting when plotting boundaries.
It appears that
boundary=administrative [0x1c resolution 24]
gets plotted 2x
ie I examined the subfile and noticed 2 identical bitstreams at different offsets, within the same subfile.
Only the lbl pointers are different.
I wonder if this doubling is necessary as it increases the img file?
Regards
Nick
-- View this message in context: http://gis.19327.n5.nabble.com/multiple-boundary-lines-tp5817950.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd A good suggestion but I'm afraid its not what is happening. I forgot to mention that I have checked my style files just in case I have the boundary plotted else where with a 'continue' I've even changed the type number to a higher one to make absolutely sure that the boundary lines are unique. What is happening is that within the resolution 24 subfile I get the same bitstream starting with the same unique type number Have tried it with the latest default style and get the same effect. if you look at offsets 3DA2 , 3DE6 , 3D2A 3E6E , I get the same 1C line, same bitstream etc, but with different lbl pointers - some don't seem to point to any text. It looks as if there might be a limit to the length of a caption within lbl so that it has to be split ? Have posted img at : www.pinns.co.uk/mps/map.img regards nick -- View this message in context: http://gis.19327.n5.nabble.com/multiple-boundary-lines-tp5817950p5818215.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Nick
if you look at offsets 3DA2 , 3DE6 , 3D2A 3E6E , I get the same 1C line, same bitstream etc, but with different lbl pointers - some don't seem to point to any text.
It looks like a case where borders at different admin levels share a line. The labels of your examples are SOUTH WEST ENGLAND, EAST DEVON DISTRICT, SIDMOUTH CP and DEVON. If you are not seeing those names you have perhaps forgotten to multiply the LBL offsets by 2. The boundaries are probably relations, so multiple relations reference the same input line with different admin_level and/or boundary=* values which produce a separate line in the output for each relation. ..Steve
Hi Steve Many thanks for that ! That explains it ! 'If you are not seeing those names you have perhaps forgotten to multiply the LBL offsets by 2. ' Oops ! Many thanks again for this input! regards Nick On 23/09/2014 11:25, Steve Ratcliffe [via GIS] wrote:
Hi Nick
if you look at offsets 3DA2 , 3DE6 , 3D2A 3E6E , I get the same 1C line, same bitstream etc, but with different lbl pointers - some don't seem to point to any text.
It looks like a case where borders at different admin levels share a line. The labels of your examples are SOUTH WEST ENGLAND, EAST DEVON DISTRICT, SIDMOUTH CP and DEVON.
If you are not seeing those names you have perhaps forgotten to multiply the LBL offsets by 2.
The boundaries are probably relations, so multiple relations reference the same input line with different admin_level and/or boundary=* values which produce a separate line in the output for each relation.
..Steve _______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5818241&i=0> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/multiple-boundary-lines-tp5817950p5818241.htm...
To unsubscribe from multiple boundary lines, click here <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5817950&code=b3NtQHBpbm5zLmNvLnVrfDU4MTc5NTB8MTM1NTM3MTE1MQ==>. NAML <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://gis.19327.n5.nabble.com/multiple-boundary-lines-tp5817950p5818242.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (3)
-
Gerd Petermann -
nwillink -
Steve Ratcliffe