Re: [mkgmap-dev] Patches ignore oneway tag for non-routable lines
Arg, I was too fast. @Ticker: I think I got you wrong. The *-Ticker.patch can be ignored. Both patches set the direction flag for oneway roads. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Samstag, 15. Mai 2021 20:30 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Patches ignore oneway tag for non-routable lines Hi all, following the discussion about commit r4715 here is a small patch to change mkgmap so that it doesn't set the direction flag in IMG when an OSM way has a oneway=1 or oneway=-1 tag when the corresponding line is not a road (a routable line with roadclass or road speed). Two patches because Ticker suggests to evaluate oneway also for lines and assume that the style will set mkgmap:has-direction=no to overwrite it. The other patch simply doesn't evaluate oneway for the direction flag. This gives smaller image files for styles which wee not yet changed. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Patches ignore oneway tag for non-routable lines
Hi all, following the discussion about commit r4715 here is a small patch to change mkgmap so that it doesn't set the direction flag in IMG when an OSM way has a oneway=1 or oneway=-1 tag when the corresponding line is not a road (a routable line with roadclass or road speed). Two patches because Ticker suggests to evaluate oneway also for lines and assume that the style will set mkgmap:has-direction=no to overwrite it. The other patch simply doesn't evaluate oneway for the direction flag. This gives smaller image files for styles which wee not yet changed. Gerd ignore-oneway-for-lines-Ticker.patch Description: ignore-oneway-for-lines-Ticker.patch ignore-oneway-for-lines.patch Description: ignore-oneway-for-lines.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [Patches] if-then and rule-index
Hi, Attached are two patches to address some of the problems in the if-then branch. - rule_index_v1.patch: This changes the index so that the example posted here works: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026311.html I guess it will have a small impact on performance because it is likely that more rules are evaluated. - if-then-reader-v1.patch This addresses the problems posted here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026290.html The unpatched code created a new ExpressionReader for the expressions in the if statement instead of using the existing one. As a result, the getUsedTags() method did not return all used tags. Gerd rule_index_v1.patch Description: rule_index_v1.patch if-then-reader-v1.patch Description: if-then-reader-v1.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patches
Am Samstag, 7. Februar 2015, 11:21:53 schrieb Steve Ratcliffe: I like the idea of having patches where they can be viewed and tracked. Having a build available for the patch would be a good idea too. So I will look into adding this Please be sure, that no one add a patch with a backdoor or other ugly code Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patches
Hi Gerd again and again users report that they don't know what to do with patches. Do you think it would be possible to implement a service onhttp://www.mkgmap.org.uk/ which allows to upload a patch to get a binary? I like the idea of having patches where they can be viewed and tracked. Having a build available for the patch would be a good idea too. So I will look into adding this Cheers ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patches
Moving the code to github would allow users to submit pull requests. It wouldn't produce a binary, but it would make the patches much more manageable. On Fri, Jan 30, 2015 at 5:45 AM GerdP gpetermann_muenc...@hotmail.com wrote: Hi Steve, again and again users report that they don't know what to do with patches. Do you think it would be possible to implement a service on http://www.mkgmap.org.uk/ which allows to upload a patch to get a binary? Gerd -- View this message in context: http://gis.19327.n5.nabble. com/patches-tp5831932.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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] patches
Hi Steve, again and again users report that they don't know what to do with patches. Do you think it would be possible to implement a service on http://www.mkgmap.org.uk/ which allows to upload a patch to get a binary? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/patches-tp5831932.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] patches
On 11/11/14 08:41, Gerd Petermann wrote: 2) Reg. the patch for RuleFileReader: I leave that to Steve or WanMil. I think it can be configured in the logging.properties as well. OK I'll change it. Cheers ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patches
Hi Brian,
Thanks for the feedback.
On Thu, Nov 6, 2014 at 3:13 AM, Brian Egge briane...@gmail.com wrote:
snip
The NYC addresses are working well. I have a minor correction as follows:
Index: resources/styles/default/inc/address
===
--- resources/styles/default/inc/address (revision 3342)
+++ resources/styles/default/inc/address (working copy)
@@ -66,8 +66,11 @@
# New York City has different admin levels than the rest of the US.
# https://wiki.openstreetmap.org/wiki/United_States_admin_level
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='New York County' { set mkgmap:city='New York' }
-mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='The Bronx' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='Bronx' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Kings County' { set mkgmap:city='Brooklyn' }
+# Queens uses neighborhoods for city in postal addresses
+# http://en.wikipedia.org/wiki/List_of_Queens_neighborhoods
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' { set mkgmap:city='Queens' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Richmond County' { set mkgmap:city='Staten Island' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8|subst:City of }’ }
One always says ‘The Bronx’, but in addresses is it’s simply Bronx. For
Queens, the neighborhood is used in mailing addresses, though sometimes
people will use ‘Queens’ instead. If you look up 40-01 43 AVENUE”
www.usps.com, it says the standardized address is:
4001 43RD AVE
SUNNYSIDE NY 11104-3205
But, the school board
http://schools.nyc.gov/SchoolPortals/30/Q150/default.htm lists it’s
address as:
40-01 43 AVENUE
QUEENS, NY11104
While the school itself https://sites.google.com/site/ps150queens/ says
it’s address is:
40-01 43 Avenue Sunnyside, NY 11104
If I’m given an address, most likely it will have the neighborhood in it,
and not ‘Queens’.
I briefly looked into this as well and you are correct. Good catch, thanks.
@Gerd (or other mkgmap developers): Can you update the address rules for
NYC with Brian's patch. Thanks.
Here’s an alternative patch to pick up place_name:
Index: src/uk/me/parabola/mkgmap/build/LocatorUtil.java
===
--- src/uk/me/parabola/mkgmap/build/LocatorUtil.java (revision 3342)
+++ src/uk/me/parabola/mkgmap/build/LocatorUtil.java (working copy)
@@ -28,7 +28,7 @@
.compile([,\\s]+);
public static ListString getNameTags(Properties props) {
- String nameTagProp = props.getProperty(name-tag-list, name);
+ String nameTagProp = props.getProperty(name-tag-list,
name,place_name);
return Arrays.asList(COMMA_OR_SPACE_PATTERN.split(nameTagProp));
}
I think it makes sense to have this in mkgmap. Personally I prefer the
patch which displays a warning message so that I can include it in the list
of warnings to fix on my website. But I guess the mkgmap developers are in
the best position to decide which is best. If this solution is chosen, a
comment would be useful - maybe just indicate that 'place_name' is only
included for compatibility with an old tag. Perhaps place_name would be
removed in the future when it's no longer in OSM.
Your other patches seem ok to me but I'm probably not the best person to
review them. :)
Thanks again for this work.
Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] patches
Thanks Ben for the hints with the boundary files. It looks like they are
published weekly on the site you linked to. I modify my build script to
download them when they change:
wget -N --user-agent=www.theeggeadventure.com
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea.zip
wget -N --user-agent=www.theeggeadventure.com
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip
The NYC addresses are working well. I have a minor correction as follows:
Index: resources/styles/default/inc/address
===
--- resources/styles/default/inc/address(revision 3342)
+++ resources/styles/default/inc/address(working copy)
@@ -66,8 +66,11 @@
# New York City has different admin levels than the rest of the US.
# https://wiki.openstreetmap.org/wiki/United_States_admin_level
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='New York County' { set mkgmap:city='New York' }
-mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='The Bronx' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='Bronx' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Kings County' { set mkgmap:city='Brooklyn' }
+# Queens uses neighborhoods for city in postal addresses
+# http://en.wikipedia.org/wiki/List_of_Queens_neighborhoods
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' { set mkgmap:city='Queens' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Richmond County' { set mkgmap:city='Staten Island' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8|subst:City of }’ }
One always says ‘The Bronx’, but in addresses is it’s simply Bronx. For Queens,
the neighborhood is used in mailing addresses, though sometimes people will use
‘Queens’ instead. If you look up 40-01 43 AVENUE” www.usps.com
http://www.usps.com/, it says the standardized address is:
4001 43RD AVE
SUNNYSIDE NY 11104-3205
But, the school board
http://schools.nyc.gov/SchoolPortals/30/Q150/default.htm lists it’s address
as:
40-01 43 AVENUE
QUEENS, NY11104
While the school itself https://sites.google.com/site/ps150queens/ says it’s
address is:
40-01 43 Avenue Sunnyside, NY 11104
If I’m given an address, most likely it will have the neighborhood in it, and
not ‘Queens’.
Here’s an alternative patch to pick up place_name:
Index: src/uk/me/parabola/mkgmap/build/LocatorUtil.java
===
--- src/uk/me/parabola/mkgmap/build/LocatorUtil.java(revision 3342)
+++ src/uk/me/parabola/mkgmap/build/LocatorUtil.java(working copy)
@@ -28,7 +28,7 @@
.compile([,\\s]+);
public static ListString getNameTags(Properties props) {
- String nameTagProp = props.getProperty(name-tag-list, name);
+ String nameTagProp = props.getProperty(name-tag-list,
name,place_name);
return Arrays.asList(COMMA_OR_SPACE_PATTERN.split(nameTagProp));
}
Can we reduce the logging from the RuleFileReader by default? It produces a
huge amount of output which probably isn’t useful unless you are debugging the
rule reader.
Index: src/uk/me/parabola/mkgmap/osmstyle/RuleFileReader.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/RuleFileReader.java (revision 3342)
+++ src/uk/me/parabola/mkgmap/osmstyle/RuleFileReader.java (working copy)
@@ -243,7 +243,7 @@
* from the expression.
*/
private void saveRule(TokenScanner scanner, Op op, ActionList actions,
GType gt) {
- log.info(EXP, op, , type=, gt);
+ log.debug(EXP, op, , type=, gt);
// check if the type definition is allowed
if (inFinalizeSection gt != null)
Here’s a bit friendlier documentation:
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 3342)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy)
@@ -926,7 +926,10 @@
}
else {
mp = new MapPoint();
- log.warn(Motorway exit, node.getName(), ( +
node.getLocation().toOSMURL() + ) has no
Re: [mkgmap-dev] patches
On Thu, Nov 6, 2014 at 12:13 AM, Brian Egge briane...@gmail.com wrote:
public static ListString getNameTags(Properties props) {
- String nameTagProp = props.getProperty(name-tag-list, name);
+ String nameTagProp = props.getProperty(name-tag-list,
name,place_name);
place_name is a key that should be fixed in OSM itself:
http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patches
I agree it should be fixed in OSM. I recently submitted a patch to JOSM to
flag this in the validation.
https://josm.openstreetmap.de/ticket/10693
There are still about 25,000 objects with place_name in them:
https://taginfo.openstreetmap.org/keys/place_name
That's too many for me to fix, and I'm not keen on trying to do a mass tag
change.
Since this tag is widely used for cities, I'd like for mkgmap to read it
in.
On Wed Nov 05 2014 at 9:45:37 PM Nelson A. de Oliveira nao...@gmail.com
wrote:
On Thu, Nov 6, 2014 at 12:13 AM, Brian Egge briane...@gmail.com wrote:
public static ListString getNameTags(Properties props) {
- String nameTagProp = props.getProperty(name-tag-list, name);
+ String nameTagProp = props.getProperty(name-tag-list,
name,place_name);
place_name is a key that should be fixed in OSM itself:
http://wiki.openstreetmap.org/wiki/Proposed_features/drop_
recommendation_for_place_name
___
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
[mkgmap-dev] [PATCHES v1] Perfomance and memory improvements
Hi,
attached are 5 patches with slightly performance improvements and
noticable max memory reductions.
free_mem_earlier_v1:
The coords map is released before the hooks are started. The coords are
used only while the input data is loaded. Additionally all hooks release
their data at the end of their end() method.
I measured the maximum memory usage by compiling a big tile and
minimizing the -Xmx parameter so that no OutOfMemoryError occurred.
Using the patch I could compile the big tile with 9% less memory.
free_nodes_ways_earlier_v1:
All OSM nodes and ways were removed only after they have been completely
converted. This patch releases each OSM object just after it has been
converted to the intermediate MapElement object.
tags_v1:
This patch removes some autoboxing (Integer to int) from heavily used
methods. I don't know if there still is a penalty for autoboxing with
current JREs. But it feels better not to use autoboxing.
polyline_addpoints_v1:
Instead of adding point by point to a polyine the patch adds full list
of points. Arraylists containing the points need to be resized once only
instead of multiple times.
clipping_v1:
The makeBoundaryNodes method clips all ways to the bounding box. But it
has to workout all nodes if the way is completely withing the bbox. The
patch avoids that.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java (revision 2346)
+++ src/uk/me/parabola/mkgmap/reader/osm/ElementSaver.java (working copy)
@@ -230,15 +230,25 @@
for (Relation r : relationMap.values())
converter.convertRelation(r);
- for (Node n : nodeMap.values())
- converter.convertNode(n);
-
+ // copy the nodes to a separate array so that the mem consuming nodeMap can be released
+ Node[] nodes = nodeMap.values().toArray(new Node[nodeMap.size()]);
nodeMap = null;
-
- for (Way w: wayMap.values())
- converter.convertWay(w);
+ for (int i = 0; i nodes.length; i++) {
+ converter.convertNode(nodes[i]);
+ // the node is no longer used and can be gc'ed
+ nodes[i] = null;
+ }
+ nodes = null;
+ // copy the ways to a separate array so that the mem consuming wayMap can be released
+ Way[] ways = wayMap.values().toArray(new Way[wayMap.size()]);
wayMap = null;
+ for (int i = 0; i ways.length; i++) {
+ converter.convertWay(ways[i]);
+ // the way is no longer used and can be gc'ed
+ ways[i] = null;
+ }
+ ways = null;
converter.end();
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (revision 2345)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -1114,8 +1114,7 @@
pl.setDirection(line.isDirection());
- for (Coord co : line.getPoints())
-pl.addCoord(co);
+ pl.addCoords(line.getPoints());
pl.setType(line.getType());
@@ -1147,8 +1146,7 @@
Polygon pg = div.createPolygon(shape.getName());
- for (Coord co : shape.getPoints())
-pg.addCoord(co);
+ pg.addCoords(shape.getPoints());
pg.setType(shape.getType());
if(element.hasExtendedType()) {
Index: src/uk/me/parabola/imgfmt/app/trergn/Polyline.java
===
--- src/uk/me/parabola/imgfmt/app/trergn/Polyline.java (revision 2345)
+++ src/uk/me/parabola/imgfmt/app/trergn/Polyline.java (working copy)
@@ -220,6 +220,10 @@
public void addCoord(Coord co) {
points.add(co);
}
+
+ public void addCoords(ListCoord coords) {
+ points.addAll(coords);
+ }
ListCoord getPoints() {
return points;
Index: src/uk/me/parabola/mkgmap/reader/osm/Tags.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/Tags.java (revision 2345)
+++ src/uk/me/parabola/mkgmap/reader/osm/Tags.java (working copy)
@@ -55,9 +55,9 @@
capacity = INIT_SIZE;
}
- public String get(Object key) {
- Integer ind = keyPos((String) key);
- if (ind == null)
+ public String get(String key) {
+ int ind = keyPos(key);
+ if (ind 0)
return null;
return values[ind];
@@ -75,8 +75,8 @@
assert key != null : key is null;
assert value != null : value is null;
ensureSpace();
- Integer ind = keyPos(key);
- if (ind == null)
+ int ind = keyPos(key);
+ if (ind 0)
assert false : keyPos( + key + ) returns null - size = + keySize + , capacity = + capacity;
keys[ind] = key;
@@ -90,10 +90,10 @@
return old;
}
- public String remove(Object key) {
- Integer k = keyPos((String) key);
+ public String remove(String key) {
+ int k = keyPos(key);
- if (k != null values[k] != null) {
+ if (k = 0 values[k] != null) {
// because of the way this works, you can never remove keys
// except when resizing.
String old = values[k];
@@ -139,7 +139,7 @@
assert keySize
