Mkgmap can read Bounds files and Style files from a zip file (and Splitter can read geonames from a zip file). Would this also be possible for precompiled sea, which comes from navmaps.eu as a zip file? Thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
Hi Roger, I am not sure, but I'll try to implement it. It will not work when the pbf reader needs random access. Gerd Roger Calvert wrote
Mkgmap can read Bounds files and Style files from a zip file (and Splitter can read geonames from a zip file). Would this also be possible for precompiled sea, which comes from navmaps.eu as a zip file?
Thanks,
Roger -- ------------------------------------------------------------------------
Roger Calvert ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750489.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
GerdP wrote
Hi Roger,
I am not sure, but I'll try to implement it. It will not work when the pbf reader needs random access.
Gerd
Hi Roger and Gerd, i'm also very unhappy to unzip this large bunch of little files in the sea.zip. This also clutters the file system alot. If pbf-format is the problem, then how about precompiled sea files in o5m-format instead of pbf-format. Would that eventually help? Regards, Uli -- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750496.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I planned to implement that but did not find time to do so. If you change the readers to be able to read from zip files it would be great! Thanks WanMil
Hi Roger,
I am not sure, but I'll try to implement it. It will not work when the pbf reader needs random access.
Gerd
Roger Calvert wrote
Mkgmap can read Bounds files and Style files from a zip file (and Splitter can read geonames from a zip file). Would this also be possible for precompiled sea, which comes from navmaps.eu as a zip file?
Thanks,
Roger -- ------------------------------------------------------------------------
Roger Calvert ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750489.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, Roger Calvert wrote
Mkgmap can read Bounds files and Style files from a zip file (and Splitter can read geonames from a zip file). Would this also be possible for precompiled sea, which comes from navmaps.eu as a zip file?
attached is a patch that implements this. @Steve, WanMil: Please review the changes in the interface LoadableMapDataSource.java. We have quite a few classes implementing this which don't really use the load method. With the patch all these classes have now two unused load methods, which is not very nice. Maybe it's better to change OsmMapDataSource to be an interface and add the additional load method only there? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750748.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Ooops, forgot to attach the patch: sea_from_zip_v1.patch <http://gis.19327.n5.nabble.com/file/n5750751/sea_from_zip_v1.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750751.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, thanks for the implementation! One general question? Should we base mkgmap on Java 7? Are there any cons? When using Java 7 we could use the new Path API which makes it easier and more transparent to read from zip files. Some notes about the patch: LoadableMapDataSource: public void load(InputStream is, String name) throws FormatException; should be public void load(InputStream is) throws FormatException; or the name should be used consistently in the readers. At the moment only the PBF reader uses the name in an error message. @Override annotations are not used yet in mkgmap sources. SeaGenerator: String precompSea = props.getProperty("precomp-sea", null); precompSeaDir = new File(precompSea); will NPE if precomp-sea is not set. Please remove System.out.* as long as it does not contain any message that are easily understandable by a user without internal knowledge. loadIndex(..) Can you please add some comments to the parmeter javadoc or remove the param javadoc? WanMil
Ooops,
forgot to attach the patch:
sea_from_zip_v1.patch <http://gis.19327.n5.nabble.com/file/n5750751/sea_from_zip_v1.patch>
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750751.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, thanks for the hints! Attached is 2nd version of the patch. I am still not really happy with the new interface LoadableOsmDataSource, but I did not find a better solution. By the way: I also tried to use o5m format for precompiled sea data, but I think it has no advantage (zip file is bigger, and the runtime of the PrecompSeaGenerator depends mostly on the mp-cut algo. Gerd
LoadableMapDataSource: public void load(InputStream is, String name) throws FormatException;
should be
public void load(InputStream is) throws FormatException;
or the name should be used consistently in the readers. At the moment only the PBF reader uses the name in an error message.
I agree. I did not notice that the name is only used in the pbf reader.
@Override annotations are not used yet in mkgmap sources.
Yes, I know. Eclipse seems to force me to use them, and I think they allow to reduce redundant javadoc. What are the cons?
SeaGenerator: String precompSea = props.getProperty("precomp-sea", null); precompSeaDir = new File(precompSea); will NPE if precomp-sea is not set.
Argh! How could I miss that?
Please remove System.out.* as long as it does not contain any message that are easily understandable by a user without internal knowledge.
sure. I first tried to implement a singleton class to allow reading the index only once, but that turned out to be slower. Did not find out why and moved back to the old way.
loadIndex(..) Can you please add some comments to the parmeter javadoc or remove the param javadoc?
done. Gerd
... and again the missing attachment: sea_from_zip_v2.patch <http://gis.19327.n5.nabble.com/file/n5750959/sea_from_zip_v2.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750959.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
WanMil wrote
One general question? Should we base mkgmap on Java 7? Are there any cons? When using Java 7 we could use the new Path API which makes it easier and more transparent to read from zip files.
I don't mind switching to Java 7, I think Java 6 will soon be out of maintenance? Reg. zip and Path API: If I got this right, this requires the zipfs.jar contained in the demo package. Is that OK for mkgmap? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5751037.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi
I don't mind switching to Java 7, I think Java 6 will soon be out of maintenance?
When we changed to Java 6, the problem was that it was not easily available on the Mac for a long time. Seems this time that Java 7 is readily available on the Mac? So if true I don't see any problem. I'd like a transition period, as with the 5 to 6 transition, where we compile to Java6 byte code and print a friendly error message that Java 7 is now required. ..Steve
Hi all, picking up loose ends... Any complains about committing this patch? http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750959.html ciao, Gerd GerdP wrote
I'd like a transition period, as with the 5 to 6 transition, where we compile to Java6 byte code and print a friendly error message that Java 7 is now required.
+1
Don't know how to do that, but sounds good to me.
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5751824.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
I would like to see it committed. I can't test it beforehand because I am not into applying patches, though. Roger On 04/03/2013 09:20, GerdP wrote:
Hi all,
picking up loose ends... Any complains about committing this patch?
http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750959.html
ciao, Gerd
GerdP wrote
I'd like a transition period, as with the 5 to 6 transition, where we compile to Java6 byte code and print a friendly error message that Java 7 is now required. +1 Don't know how to do that, but sounds good to me.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5751824.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
Hi Roger, okay, I've committed the patch as r2518. I'll update the wiki when this version is available on the download page. I'll also add that functionality to the precomp-sea option in splitter. Gerd Roger Calvert wrote
I would like to see it committed. I can't test it beforehand because I am not into applying patches, though.
Roger
On 04/03/2013 09:20, GerdP wrote:
Hi all,
picking up loose ends... Any complains about committing this patch?
http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750959.html
ciao, Gerd
GerdP wrote
I'd like a transition period, as with the 5 to 6 transition, where we compile to Java6 byte code and print a friendly error message that Java 7 is now required. +1 Don't know how to do that, but sounds good to me.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5751824.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- ------------------------------------------------------------------------
Roger Calvert ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5752211.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks, Gerd. Look forward to it. Roger On 07/03/2013 07:05, GerdP wrote:
Hi Roger,
okay, I've committed the patch as r2518. I'll update the wiki when this version is available on the download page. I'll also add that functionality to the precomp-sea option in splitter.
Gerd
Roger Calvert wrote
I would like to see it committed. I can't test it beforehand because I am not into applying patches, though.
Roger
On 04/03/2013 09:20, GerdP wrote:
Hi all,
picking up loose ends... Any complains about committing this patch?
http://gis.19327.n5.nabble.com/zip-files-tp5750468p5750959.html
ciao, Gerd
GerdP wrote
I'd like a transition period, as with the 5 to 6 transition, where we compile to Java6 byte code and print a friendly error message that Java 7 is now required. +1 Don't know how to do that, but sounds good to me.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5751824.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- ------------------------------------------------------------------------
Roger Calvert ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/zip-files-tp5750468p5752211.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
Hi
@Steve, WanMil: Please review the changes in the interface LoadableMapDataSource.java. We have quite a few
I think that the classes for precompiled tiles should implement a different interface to LoadableMapDataSource. There is no need for isFileSupported(), mapLevels() either. I would create another interface that extends MapDataSource for these kinds of situations. ..Steve
Hi Steve,
@Steve, WanMil: Please review the changes in the interface LoadableMapDataSource.java. We have quite a few
I think that the classes for precompiled tiles should implement a different interface to LoadableMapDataSource. There is no need for isFileSupported(), mapLevels() either.
I would create another interface that extends MapDataSource for these kinds of situations.
I think MapDataSource is not suitable. The SeaGenerator requires the raw OSM data (ways and nodes), not interpreted by any style. Gerd
participants (6)
-
Gerd Petermann -
GerdP
-
Roger Calvert -
Steve Ratcliffe -
UliBaer -
WanMil