date:20140102


Hi Gerd,


okay, I'll have a look at it during the next days.


Thanks!

BTW, the diagnostics is not completely useless as it is now; it does 
include labels, which (when present) will identify the ways. But, in 
addition to normally unnamed highway=service, there could be some ways 
that are accidentally left unnamed, such as when splitting a way to a 
dual carriageway near a junction (Y-shaped). Then, both oneway arms of 
the Y could accidentally point to the same direction, which would 
trigger a warning.


Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Address search: city sometimes missing

2014-01-02 Thread Steve Ratcliffe


Hi


I tried it with Mittelfranken from
http://download.geofabrik.de/europe/germany/bayern.html


OK thanks.  I tried with that file with the same result; the city is
on both buildings.

I've uploaded the relevant tile http://files.mkgmap.org.uk/detail/165
for others to try in case it is environment dependant.

..Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Hi Marko,


Marko Mäkelä wrote
 I figured out that it would be nice to display all tags of the dead-end 
 oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper 
 script could filter out any oneway warnings for highway=service.  

I am not sure if I got that right. If you want to suppress the
dead-end-check for all ways with specific tags,
you can do it in the style (add the tag mkgmap:dead-end-check=false to the
way)

Gerd



--
View this message in context: 
http://gis.19327.n5.nabble.com/Diagnostic-warnings-for-dead-end-oneway-highway-service-tp5791229p5791471.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

[mkgmap-dev] r2930 in high-prec-coord branch

Hi all,

r2930 is now up to date:
r2930: apply modified version of link-pois-to-ways-v2.patch
r2929: slightly modified closed-equal-v2.patch
r2928 merge from trunk r2927

I will try to add a merge routine for shapes (maybe only selected
ones like buildings) and further code to remove wrong
angles caused by rounding to map units the next days .

Gerd
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service


Hi Gerd,

I figured out that it would be nice to display all tags of the 
dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap 
wrapper script could filter out any oneway warnings for highway=service.


I am not sure if I got that right. If you want to suppress the 
dead-end-check for all ways with specific tags, you can do it in the 
style (add the tag mkgmap:dead-end-check=false to the way)


I do not want to suppress dead-end-checks altogether. I do it on a 
case-by-case basis, either by adding fixme=continue to the endpoint 
(this will set mkgmap:dead-end-check=false on the way; I wrote the code 
to do that), or by filtering out messages.


Here is a slightly different example:

... Motorway exit 67 
(http://www.openstreetmap.org/?mlat=60.47712mlon=26.27170zoom=17) has 
no motorway!


This is for node 1909615887. The message fails to mention the tags of 
the attached way 181498435 (highway=construction, construction=motorway, 
...).


I have a file that I pass to grep -vf for suppressing known warnings.  
I would not want to add a suppression for this message as it is now, 
because it would remain suppressed after the construction is completed 
and the way gets tagged highway=motorway. If my suppression regexp were 
something like


Motorway exit 67 .*mlat=60\.47712mlon=26\.27170.*highway=construction

then it would no longer suppress the warning if the way is changed to 
highway=motorway and some map editor breaks something. (Even better than 
coordinates would be the ID of the highway=motorway_exit node.)


Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] [PATCH] Do not create RestrictionRelation for unspecified restriction

There are a few restriction relations for no through route mapped in 
Finland. These are a bit ambiguous, because it looks like there are 
multiple possible routes, all of which are banned. These relations are 
tagged with type=restriction, but not with any restriction=*.


For mkgmap, the issue is that multiple warnings get emitted for the 
single relation. The attached patch would emit just one warning, for the 
restriction=* being missing. OK to commit?


(Side note: I think that it could be better if there was a factory 
method that created the RestrictionRelation if it is supported. It seems 
to be a waste of memory to create a RestrictionRelation object that we 
do not support, for example when there are via ways instead of via 
nodes.)


While working on this, I was wondering why we set rel=null if turn 
restrictions are being ignored. I think that the relation should be 
collected, just like any relation that does not have any magic meaning, 
so that any style rules could process the relation. I did not touch that 
part of the code.


Best regards,

Marko
Index: src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java	(revision 2916)
+++ src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java	(working copy)
@@ -144,6 +144,8 @@
 			} else if(restriction.equals(type)) {
 if (ignoreTurnRestrictions)
 	rel = null;
+else if (rel.getTag(restriction) == null)
+	log.warn(ignoring unspecified restriction  + rel.toBrowseURL());
 else
 	rel = new RestrictionRelation(rel);
 			}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Hi Marko,

okay, let me know if the patch works for you.

Gerd

Marko Mäkelä wrote
 Hi Gerd,
 
I figured out that it would be nice to display all tags of the 
dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap 
wrapper script could filter out any oneway warnings for highway=service.

I am not sure if I got that right. If you want to suppress the 
dead-end-check for all ways with specific tags, you can do it in the 
style (add the tag mkgmap:dead-end-check=false to the way)
 
 I do not want to suppress dead-end-checks altogether. I do it on a 
 case-by-case basis, either by adding fixme=continue to the endpoint 
 (this will set mkgmap:dead-end-check=false on the way; I wrote the code 
 to do that), or by filtering out messages.
 
 Here is a slightly different example:
 
 ... Motorway exit 67 
 (http://www.openstreetmap.org/?mlat=60.47712mlon=26.27170zoom=17) has 
 no motorway!
 
 This is for node 1909615887. The message fails to mention the tags of 
 the attached way 181498435 (highway=construction, construction=motorway, 
 ...).
 
 I have a file that I pass to grep -vf for suppressing known warnings.  
 I would not want to add a suppression for this message as it is now, 
 because it would remain suppressed after the construction is completed 
 and the way gets tagged highway=motorway. If my suppression regexp were 
 something like
 
 Motorway exit 67 .*mlat=60\.47712mlon=26\.27170.*highway=construction
 
 then it would no longer suppress the warning if the way is changed to 
 highway=motorway and some map editor breaks something. (Even better than 
 coordinates would be the ID of the highway=motorway_exit node.)
 
   Marko
 ___
 mkgmap-dev mailing list

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/Diagnostic-warnings-for-dead-end-oneway-highway-service-tp5791229p5791489.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

[mkgmap-dev] Commit: r2931: Fix syntax typo in one of the headings.

2014-01-02 Thread svn commit


Version mkgmap-r2931 was committed by steve on Thu, 02 Jan 2014

Fix syntax typo in one of the headings.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH] Do not create RestrictionRelation for unspecified restriction

Hi Marko,

the patch looks good to me.
Typically there are only a few hundred relations in one tile, so I do not 
expect 
a big change in performance if we don't create objects for the very few 
relations that we don't supprt.
I think it is ok to ignore the restriction, because we have no other code to 
interpret it.

Gerd
 
Date: Thu, 2 Jan 2014 19:37:28 +0200
From: marko.mak...@iki.fi
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] [PATCH] Do not create RestrictionRelation for 
unspecified restriction

There are a few restriction relations for no through route mapped in 
Finland. These are a bit ambiguous, because it looks like there are 
multiple possible routes, all of which are banned. These relations are 
tagged with type=restriction, but not with any restriction=*.
 
For mkgmap, the issue is that multiple warnings get emitted for the 
single relation. The attached patch would emit just one warning, for the 
restriction=* being missing. OK to commit?
 
(Side note: I think that it could be better if there was a factory 
method that created the RestrictionRelation if it is supported. It seems 
to be a waste of memory to create a RestrictionRelation object that we 
do not support, for example when there are via ways instead of via 
nodes.)
 
While working on this, I was wondering why we set rel=null if turn 
restrictions are being ignored. I think that the relation should be 
collected, just like any relation that does not have any magic meaning, 
so that any style rules could process the relation. I did not touch that 
part of the code.
 
Best regards,
 
Marko

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

On Thu, Jan 02, 2014 at 04:27:23PM +0100, Gerd Petermann wrote:
attached is a patch for the high-prec-coord branch to perform the
dead-end-check in StyledConverter.
I did not remove the original code, so both tests are performed now. I
think this helps to find differences.

Thanks! This looks verbose enough for my taste:

2014/01/02 19:42:16 WARNING (StyledConverter): 63240004.osm.pbf: Oneway
road 55835321 with tags
[oneway=yes,mkgmap:street=Pentinkaarre,name=Pentinkaarre,mkgmap:label:1=Pentinkaarre,highway=living_street,surface=paved]
goes to nowhere at
http://www.openstreetmap.org/?mlat=62.262185mlon=24.710546zoom=17

Maybe you could filter out the generated mkgmap:* tags, but I am OK with
it. I guess that the logging output is too verbose to be read directly
by a human anyway (without any searching or filtering, that is).

This way is (was) P-shaped. The oneway=yes would be OK for the D-shaped
loop of the P, but not for the 'foot'. I fixed this particular error,
but left others there, so that we can do more cross-checking with
subsequent patches.

I got 23 Oneway warnings with your branch+patch, and 13 with trunk. The
differences are as follows, after filtering out timestamps and sorting
both outputs:

* Different coordinates for the 13 old messages (as expected; this is
thanks to the higher precision)

* 'Extra' warning for the ways: 55835321 23152992 64148077 167346021
* 'Missing' warning for the ways: 200035193 220389737 25455464 42191422
53197410 131648853 50118184

The 'missing' warnings could be because the ways are connected to other
ways for which map is not being generated, such as a
highway=service,oneway=yes leading to a
highway=service,oneway=yes,tunnel=yes,... that is omitted from the map.

IMO the 'missing' warnings should be emitted; we should be checking that
the generated map makes sense.

Please note that both checks will not recognize restriction relations
which prohibit to enter or leave a oneway.

Right. Ignorance is bliss. :)

A related note with oneways is that some mappers seem to generate
redundant turn restrictions for oneways. For example, they would add a
relation that prevents turning against the oneway from a motorway_link
to the motorway lane. I wonder if we should emit warnings for such
redundant relations?

Best regards,

Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH] Do not create RestrictionRelation for unspecified restriction


Gerd,

thanks for the review. I will wait a bit before committing to trunk, in 
case someone has another opinion.


I think it is ok to ignore the restriction, because we have no other 
code to interpret it.


My point is that there could be a style rule to interpret the 
type=restriction relation. (Maybe someone wants to create a map layer 
containing all ways or nodes participating in restrictions.)


So, it would seem like a bug to silently discard the type=restriction 
relation if the built-in processing of it is disabled by a command-line 
option. But, I guess that we can leave it as is for now.


Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Hi Marko,
  
please check:

Marko Mäkelä wrote
 * Different coordinates for the 13 old messages (as expected; this is 
 thanks to the higher precision)

I don't yet see a reason for different coordinates. Did you really compare
the output one program execution?
Or did you use a different program for the old messages?

Gerd



--
View this message in context: 
http://gis.19327.n5.nabble.com/Diagnostic-warnings-for-dead-end-oneway-highway-service-tp5791229p5791504.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

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service


On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:

Hi Marko,

please check:

Marko Mäkelä wrote

* Different coordinates for the 13 old messages (as expected; this is
thanks to the higher precision)


I don't yet see a reason for different coordinates. Did you really compare
the output one program execution?
Or did you use a different program for the old messages?


I did 2 comparisons with the output from 2 runs:

With mkgmap/trunk r2916
With mkgmap/branches/high-prec-coord r2930 and your patch

First, I compared the output of trunk to the output of branch, using the 
finland.osm.pbf from Geofabrik dated today, 02:16 UTC.


There were 2 differences:

(a) Variation of the coordinates in the 13 old-style messages
(b) Addition of 10 new-style messages

This was to be expected.

What was not expected was the difference 13 vs. 10. To diagnose it,
I performed another comparison within the output of the patched branch.  
Many of the old messages had direct counterparts in the new 
messages, but some new messages for old messages were missing, and 
some were extra (only new message for the way, no old one).


In my previous message, I listed the OSM way IDs for both cases. I fixed 
one error (for one extra new message) in the OSM database, but I left 
the others intact, so that we will have some errors in the next 
finland.osm.pbf to check against.


Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Hi Marko,

okay, thanks for the explanation. I'll look at the differences tomorrow.

Gerd

Marko Mäkelä wrote
On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:
Hi Marko,

please check:

Marko Mäkelä wrote
* Different coordinates for the 13 old messages (as expected; this is
thanks to the higher precision)

I don't yet see a reason for different coordinates. Did you really compare
the output one program execution?
Or did you use a different program for the old messages?

I did 2 comparisons with the output from 2 runs:

With mkgmap/trunk r2916
With mkgmap/branches/high-prec-coord r2930 and your patch

First, I compared the output of trunk to the output of branch, using the
finland.osm.pbf from Geofabrik dated today, 02:16 UTC.

There were 2 differences:

(a) Variation of the coordinates in the 13 old-style messages
(b) Addition of 10 new-style messages

This was to be expected.

What was not expected was the difference 13 vs. 10. To diagnose it,
I performed another comparison within the output of the patched branch.
Many of the old messages had direct counterparts in the new
messages, but some new messages for old messages were missing, and
some were extra (only new message for the way, no old one).

In my previous message, I listed the OSM way IDs for both cases. I fixed
one error (for one extra new message) in the OSM database, but I left
the others intact, so that we will have some errors in the next
finland.osm.pbf to check against.

Marko
___
mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context:
http://gis.19327.n5.nabble.com/Diagnostic-warnings-for-dead-end-oneway-highway-service-tp5791229p5791507.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

Re: [mkgmap-dev] mergeroads sometimes breaks routing

Hi,
 
 thanks for reporting! Without having had a detailed look at your test 
 case it sounds like the same problem reported by Gerd: 
 http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q4/019532.html

I forgot to report that changing the order of nodes did not change the 
result in MapSource, so this is a different problem.

Gerd

  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] invalid types in check-styles

Hi all,

got no answer on the question what mkgmap should 
do with a type like 0x11f in the lines file.
The current behaviour is that it quietly ignores 
the error because it treats 0x11f like 0x1f.
I'd prefer to write an error message and 
completely ignore the corresponding line in the style.

Gerd 


nwillink wrote
 Hi Gerd
 
 No , its only the style checker that throws up the anomaly.
 
 I might have missed something about mkgmap requiring 00 subtypes ? 
 although I have not encountered
 any problems leaving them out for extended types
 
 The highest subtype is 1F and the highest type for lines/polylines, I 
 think, 1FF making 1FF1F the  highest number.
 
 
 On 30/12/2013 17:17, GerdP [via GIS] wrote:
 Hi Nick,

 well, 0x11f00 is 256 * 0x11f, so it is not the same, but
 if I get you right you want mkgmap to interpret all values = 0x100 and x
 as if they were written with a 00 at the end.
 What is the upper bound (x) ?

 See also
 http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017797.html

 Gerd

 
 Date: Mon, 30 Dec 2013 08:04:31 -0800
 From: [hidden email]
 lt;/user/SendEmail.jtp?type=nodeamp;node=5791215amp;i=0gt;
 To: [hidden email]
 lt;/user/SendEmail.jtp?type=nodeamp;node=5791215amp;i=1gt;
 Subject: Re: [mkgmap-dev] invalid types in check-styles

 Hi Gerd

 0x11f is the same as 0x11f00 - both have been valid expressions in the 
 past.

 However, the style checker tells me that 11f is invalid.
 This applies to I think all extended types , ie it tells me 10A 
 (without the 00) is invalid.
 It accepts 10A00 but not 10A
 It accepts 11F00 but not 11F
 I agree 10A00 is the more accurate way of defining an extended line 
 but it might be confusing to flag them as invalid.

 r

 Nick


 On 30/12/2013 15:49, GerdP [via GIS] wrote:

 Hi,

 yes, 0x11f00 is recognized as an extended type.
 What bug do you mean?
 Should mkgmap interpret 0x11f as 0x11f00
 when used in the lines or polygons file?

 Gerd

  Date: Mon, 30 Dec 2013 02:07:24 -0800

  From: [hidden email]
 lt;http:///user/SendEmail.jtp?type=nodeamp;node=5791203amp;i=0gt;
  To: [hidden email]
 lt;http:///user/SendEmail.jtp?type=nodeamp;node=5791203amp;i=1gt;
  Subject: [mkgmap-dev] invalid types in check-styles
 
  Hi
 
  Interesting 'bug' when using check-styles.
 
  It had me foxed as it actually by chance highlighted lines I
 didn't use in
  my TYP file.
 
  invalid type 0x11f for POLYLINE
 
  It transpires that when replacing 11f with 11f00 the type number is
  correctly identified as valid.
  I checked it with several lines, with and without the zero
 subtypes.
 
 
 
 
 
  --
  View this message in context:

 http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157.html
  Sent from the Mkgmap Development mailing list archive at
 Nabble.com.
  ___
  mkgmap-dev mailing list
  [hidden email]
 lt;http:///user/SendEmail.jtp?type=nodeamp;node=5791203amp;i=2gt;
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

 ___
 mkgmap-dev mailing list
 [hidden email]
 lt;http:///user/SendEmail.jtp?type=nodeamp;node=5791203amp;i=3gt;
 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/invalid-types-in-check-styles-tp5791157p5791203.html

 To unsubscribe from invalid types in check-styles, click here
 lt;http://gt;.
 NAML

 lt;http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_vieweramp;id=instant_html%21nabble:email.namlamp;base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespaceamp;breadcrumbs=notify_subscribers%21nabble:email.naml-instant_emails%21nabble:email.naml-send_instant_email%21nabble:email.namlgt;




 
 View this message in context: Re: invalid types in check-styles 
 lt;http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p5791212.htmlgt;
 Sent from the Mkgmap Development mailing list archive 
 lt;http://gis.19327.n5.nabble.com/Mkgmap-Development-f5324443.htmlgt;
 at 
 Nabble.com.

 ___ mkgmap-dev mailing 
 list [hidden email]
 lt;/user/SendEmail.jtp?type=nodeamp;node=5791215amp;i=2gt; 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

 ___
 mkgmap-dev mailing list
 [hidden email]
 lt;/user/SendEmail.jtp?type=nodeamp;node=5791215amp;i=3gt;
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] invalid types in check-styles

2014-01-02 Thread Steve Ratcliffe


On 02/01/14 22:00, GerdP wrote:

got no answer on the question what mkgmap should
do with a type like 0x11f in the lines file.
The current behaviour is that it quietly ignores
the error because it treats 0x11f like 0x1f.


I would say that it is an error.

I break the full type down as follows:

0xXYYZZ

X is a flag for 'extended type' (0 or 1)
YY is the type
ZZ is the subtype (max 0x1f)

I would always recommend using the full types, since the short forms
cause so much confusion.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] invalid types in check-styles

Hi Steve,

yes, it is an error. But how do you suggest to change mkgmap?
The default style uses 0xYY in lines and polygons file, as we don't
use extended types, and the range for YY is 00 to 3f for lines
and 00 to 7f for polygons, and sub types are not supported for them. 
Should we interpret 0x3f00 like 0x3f and 0x11f like 0x11f00 ?
If yes, should this produce an error message like
style abc, file lines, line xyz, interpreting type 0x3f00 as 0x3f
style abc, file polygons, line xyz, interpreting type 0x11f as extended type
0x11f00.

Or do you vote for a change so that the user always has to write 0xXYYZZ ?

Gerd




Steve Ratcliffe wrote
 On 02/01/14 22:00, GerdP wrote:
 got no answer on the question what mkgmap should
 do with a type like 0x11f in the lines file.
 The current behaviour is that it quietly ignores
 the error because it treats 0x11f like 0x1f.
 
 I would say that it is an error.
 
 I break the full type down as follows:
 
 0xXYYZZ
 
 X is a flag for 'extended type' (0 or 1)
 YY is the type
 ZZ is the subtype (max 0x1f)
 
 I would always recommend using the full types, since the short forms
 cause so much confusion.
 
 ..Steve
 ___
 mkgmap-dev mailing list

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/invalid-types-in-check-styles-tp5791157p5791519.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

Re: [mkgmap-dev] routing seems to depend on order of ways

2014-01-02 Thread Steve Ratcliffe



Hi Gerd,

Nice simple test case. I can reproduce on a similar version of mapsource
that you used, but not on an older version.


I hope you can reproduce the problem and find out what goes wrong...


Interestingly if set to shortest time and avoid u-turns, then it goes
straight down w1, w2 and through the barrier to the destination. It
doesn't go along w3 at all.  This happens on good (and bad I think but
I would have to re-check).

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] routing seems to depend on order of ways

Hi Steve,
 Nice simple test case. I can reproduce on a similar version of mapsource
 that you used, but not on an older version.
 
  I hope you can reproduce the problem and find out what goes wrong...
 
 Interestingly if set to shortest time and avoid u-turns, then it goes
 straight down w1, w2 and through the barrier to the destination. It
 doesn't go along w3 at all.  This happens on good (and bad I think but
 I would have to re-check).
yes, the original test was without w3. I wanted to prove that the 
link-pois-to-ways-v2.patch doesn't change something to the worse
as feared by Chris66 :
http://gis.19327.n5.nabble.com/patch-v1-link-pois-to-ways-and-restrictions-tp5790650p5790923.html

The test proved that, so I wanted to find out what MapSource does if there is 
an 
alternative connection which is much longer. Result is the test case.
Later, I've modified w3 to be much shorter, but that did not change 
anything to the better, means, all results with wrong routes were the same.

Gerd

  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service