Re: [mkgmap-dev] Multipolygons
Steve Ratcliffe wrote: Hi I am going to merge all the multipolygon fixes. Including, if appropriate, the sea polygon changes. In addition to the patches sent to the list I also have permission to use the attached patch from Olaf Kähler which he describes as follows: I guess, mkgmap has a bug with vanishing islands in case of multipolygons. The major problem seems to be, that in the polygon splitting process (PolygonSplitterBase.java), the Java awt methods mess around with the inner polygons, that were previously merged into the outer polygons. I included a patch, that somewhat works, but still seems to have a few issues. I've also included sample .osm files to explain these issues: I'd appreciate it if anyone who understands the polygon issues takes a look at the patch. Also if you have an test cases which don't work with the current trunk but might be fixed by the outstanding patches let me know. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev I tested the three samples with build 1129 before and after applying the patch. Before patch test1=lake with island level0=fail (Island missing) level1=okay level2=okay test2=lake with 2 islands level0=fail (Islands missing) level1=okay level2=okay test3=lake with island + small lake on island level0=fail (Island small lake missing) level1=okay level2=okay After patch test1 all okay test2 all okay test3 level0=fail (Island small lake missing) level1=okay level2=okay So test 3 still fails, even after applying the patch, or did I do something wrong applying the patch? The patch failed to apply properly for me, and I had to fix some errors by hand, so I could have made a mistake. I will test my own samples next. Thanks for the updates, Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing with the default style
Hello Nop, I am just having my first look at creating a routable map. It appears that the default style completely disregards the access tags access=no, vehicle=no, motorvehicle=no and motorcar=no. Naturally I'd like to exclude these from routing, but there seem to be no rules evaluating them in the default style. Is this really the case or are those tags somehow hardcoded in mkgmap? The tags vehicle and motorvehicle are not recognised so you will need to add style rules to convert them to one of the access tags that are recognised which are: access (applies to everything) bicycle foot hgv motorcar motorcycle (same as motorcar) psv taxi emergency delivery goods (same as delivery) Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
private int roundDown(int val) {
return val SHIFT SHIFT;
}
I would write this as
return val ~(1 SHIFT);
That's not the same thing though. I assume you really mean:
return val ~((1 SHIFT) - 1);
And in fact that's what was there originally for positive numbers. Negative
numbers were handled differently, for reasons I don't understand (hence why
I'm asking on here).
I think I still prefer val SHIFT SHIFT, it's clearer what's happening
(to me at least, I appreciate everything thinks about these things
differently).
It's also fewer clock cycles unless you're on a 286 or lower ;) Though the
clock cycle argument isn't relevant here, the code is only called twice during
the entire split!
private int roundUp(int val) {
return (val + (1 SHIFT) - 1) SHIFT SHIFT;
}
And this one as
return (val + ((1 SHIFT) - 1))) ~(1 SHIFT);
Again, that would need to be (val + ((1 SHIFT) - 1))) ~((1 SHIFT)
- 1);
It's probably not a big deal, but if SHIFT is a compile-time constant
and the compiler performs constant folding, the run-time code should
be shorter and faster.
Yep I'd seen that and had originally coded it that way. I've now actually
moved the code to the Utils class and passed 'shift' in as a parameter for
flexibility, and because in this case performance doesn't matter.
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
On Tue, Aug 11, 2009 at 06:52:35AM +, Chris Miller wrote:
private int roundDown(int val) {
return val SHIFT SHIFT;
}
I would write this as
return val ~(1 SHIFT);
That's not the same thing though. I assume you really mean:
return val ~((1 SHIFT) - 1);
And in fact that's what was there originally for positive numbers. Negative
numbers were handled differently, for reasons I don't understand (hence why
I'm asking on here).
Oh, sorry, you are right, I forgot the -1.
I think I still prefer val SHIFT SHIFT, it's clearer what's happening
(to me at least, I appreciate everything thinks about these things
differently).
It's also fewer clock cycles unless you're on a 286 or lower ;) Though the
clock cycle argument isn't relevant here, the code is only called twice
during
the entire split!
If that is the case, then it is better to aim for readability and
maintainability. The bit-shifting expression should be easier to read
than the monster bit-masking expression. And because you are shifting
the same amount right and left, it won't matter whether you are using
arithmetic or logical right shift ( or in Java).
Sorry for the noise.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Better rounding in mkgmap
On Tue, Aug 11, 2009 at 3:50 PM, Elrondelrond+openstreetmap@samba-tng.org wrote: As rounding seems a current topic, I'm throwing in a patch that is sitting in my tree for a while now: How can I best test this patch? Is there something I can look for without examining the binary data of the generated map? (For example, what are typical symptoms of incorrect rounding?) Thanks! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Style additions for marine navigation markers
Hi,
I have no idea on sailing (despite I'd like to somehow).
Looking at your mods...
+man_made=pier {name '${name} (${man_made})' | '${man_made}'
1. Did you miss the } at the end? Or am I missing
something obvious?
2. Shouldn't that line before the other man_made=pier line?
Elrond
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
Chris Miller schreef: but my impression is that the conclusion was that the splitter should be rounding areas off to boundaries in multiples of 4096 rather than 2048? As far as I've seen - thanks to Steve Ratcliffe's findings - divisible by 2048 is enough, if you make sure that the difference is a multiple of 4096. (i.e. if your bounds are 0x123800 and 0x456800, that is OK; but 0x123800 and 0x456000 is not OK). Anyway, dividing by 4096 is a good method of achieving this. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Style additions for marine navigation markers
On Aug 11, 2009, at 17:59, Elrond wrote:
Looking at your mods...
+man_made=pier {name '${name} (${man_made})' | '${man_made}'
1. Did you miss the } at the end? Or am I missing
something obvious?
2. Shouldn't that line before the other man_made=pier line?
Yes, it looks like the final } got cut off in my patch. The order,
in this case, seems to be unimportant (it works properly), but yes,
this line should really come first.
Thanks for taking a look!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitting multipolygons
On 10/08/09 15:07, Nop wrote: There are other outstanding mulitpolygon fixes that may help too. The first of which is applied to the multipolygon branch: I am not sure I understand. Do maps split with splitter also have the problem of missing polygons at the moment? The splitter doesn't really know about multi polygons so there are no reasons I know why it should introduce any problems. It is just the way the work is shared between splitter and mkgmap. The splitter creates a rough oversized area and mkgmap does the difficult work of cutting the polygons to the exact boundary. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Changed build.xml for DEM generation
Hi, I'm using Linux and was searching for a way to create contour lines. Therefore I was amazed that Christian Gawron just added the functionality to mkgmap in svn. But then I realized, that it was disabled again. Therefore I would like to propose the changes to the build.xml file and the external.properties (see attached files). This would enable the GeoTIFF class build if JAI is available. By the way I'm still trying to understand the DEM functionality. Can anyone add some more information to the Wiki, e.g. - where to download the needed files, - how to set the required bounding box, - an example of the content of the directory set by --dem-path - etc. Sorry about the questions, but I'm really curious about this functionality. Regards, Jörg __ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de build.xml Description: XML document #log4j.lib= /opt/jars/jakarta-log4j-1.2.8/dist/lib #log4j.jars= log4j-1.2.8.jar #To compile GeoTiffDEM.java you'll need Java Advanced Imaging (JAI) #installed, so it is disabled by default in the build.xml. geotiffdem.build=true jai.lib=/usr/share/sun-jai-bin/lib jai.jar.codec=jai_codec.jar jai.jar.core=jai_core.jar jai.jar.mlibwrapper=mlibwrapper_jai.jar ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
