Re: [mkgmap-dev] NSIS Problems with 2G limit
Ok, but I have no idea how to change the osmmap.nsi created by the --nsis option of mkgmap, so that it did not include the .img's in the installer exe directly. Wouldn't it be usefull to have a small .exe installer in the same directory of the img files that just installs them for windows users? I am not a windows hacker and have no knowledge about the nsis system. Maybe we could add some params to the --nsis option of mkgmap like: --nsis=nodata or something to avoid including the files in the exe directly. After a mkgmap run with --nsis=nodata option a directory could contain for example the following: 63240001.img 63240002.img 63240003.img ... basemap.TYP osmmap.img osmmap_license.txt osmmap_mdr.img osmmap.mdx osmmap.nsi osmmap.tdb After makensis osmmap.nsi there should be a small .exe file not including the imgs, but install them from this directory by double clicking. What do you think? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] NSIS Problems with 2G limit
Hello, while I'm trying to build an mapsource installer with the --nsis option and makensis for the garmin all in one for europe I get the following error after a while with makensis: Internal compiler error #12345: error mmapping file (2141990789, 4569600) is out of range. Note: you may have one or two (large) stale temporary file(s) left in your temporary directory (Generally this only happens on Windows 9x). --- I will attach the whole ouput from makensis, but I think the problem is, that europe is too big now. The imgs together have a size of 2,1G. Is 2G a fix limit of this nsis stuff or is it a bug somewhere? (Yeah, I know - the bug is windows...) :) Thanks Christoph MakeNSIS v2.44-4 - Copyright 1995-2009 Contributors See the file COPYING for license details. Credits can be found in the Users Manual. Processing config: Processing plugin dlls: "/usr/share/nsis/Plugins/*.dll" - AdvSplash::show - Banner::destroy - Banner::getWindow - Banner::show - BgImage::AddImage - BgImage::AddText - BgImage::Clear - BgImage::Destroy - BgImage::Redraw - BgImage::SetBg - BgImage::SetReturn - BgImage::Sound - Dialer::AttemptConnect - Dialer::AutodialHangup - Dialer::AutodialOnline - Dialer::AutodialUnattended - Dialer::GetConnectedState - InstallOptions::dialog - InstallOptions::initDialog - InstallOptions::show - LangDLL::LangDialog - Math::Script - NSISdl::download - NSISdl::download_quiet - Splash::show - StartMenu::Init - StartMenu::Select - StartMenu::Show - System::Alloc - System::Call - System::Copy - System::Free - System::Get - System::Int64Op - System::Store - TypeLib::GetLibVersion - TypeLib::Register - TypeLib::UnRegister - UserInfo::GetAccountType - UserInfo::GetName - UserInfo::GetOriginalAccountType - VPatch::GetFileCRC32 - VPatch::GetFileMD5 - VPatch::vpatchfile - nsDialogs::Create - nsDialogs::CreateControl - nsDialogs::CreateItem - nsDialogs::CreateTimer - nsDialogs::GetUserData - nsDialogs::KillTimer - nsDialogs::OnBack - nsDialogs::OnChange - nsDialogs::OnClick - nsDialogs::OnNotify - nsDialogs::SelectFileDialog - nsDialogs::SelectFolderDialog - nsDialogs::SetRTL - nsDialogs::SetUserData - nsDialogs::Show - nsExec::Exec - nsExec::ExecToLog - nsExec::ExecToStack !define: "MUI_INSERT_NSISCONF"="" Changing directory to: "/osm/garmin/aio/europe/gbasemap" Processing script file: "/osm/garmin/aio/europe/gbasemap/osmmap.nsi" !define: "DEFAULT_DIR"="C:\Garmin\Maps\OSM-AllInOne-EU-basemap" !define: "INSTALLER_DESCRIPTION"="OSM-AllInOne-EU-basemap" !define: "INSTALLER_NAME"="OSM-AllInOne-EU-basemap" !define: "MAPNAME"="osmmap" !define: "PRODUCT_ID"="45" !define: "REG_KEY"="OSM-AllInOne-EU-basemap" SetCompressor: /SOLID lzma !include: "/usr/share/nsis/Include/MUI2.nsh" !include: "/usr/share/nsis/Contrib/Modern UI 2/MUI2.nsh" NSIS Modern User Interface version 2.0 - Copyright 2002-2009 Joost Verburg (/usr/share/nsis/Contrib/Modern UI 2/MUI2.nsh:8) !define: "MUI_INCLUDED"="" !define: "MUI_SYSVERSION"="2.0" !define: "MUI_VERBOSE"="3" !include: closed: "/usr/share/nsis/Contrib/Modern UI 2/MUI2.nsh" !include: closed: "/usr/share/nsis/Include/MUI2.nsh" !insertmacro: MUI_PAGE_WELCOME !insertmacro: end of MUI_PAGE_WELCOME !insertmacro: MUI_PAGE_LICENSE !insertmacro: end of MUI_PAGEDECLARATION_LICENSE !insertmacro: end of MUI_PAGE_LICENSE !insertmacro: MUI_PAGE_DIRECTORY !insertmacro: end of MUI_PAGE_DIRECTORY !insertmacro: MUI_PAGE_INSTFILES !insertmacro: end of MUI_PAGE_INSTFILES !insertmacro: MUI_PAGE_FINISH !insertmacro: end of MUI_PAGE_FINISH !define: "MUI_UNPAGE_INSTFILES"="" !insertmacro: MUI_LANGUAGE !insertmacro: end of MUI_LANGUAGE Name: "OSM-AllInOne-EU-basemap" OutFile: "/osm/garmin/aio/europe/gmapsupps/gbasemap/OSM-AllInOne-EU-basemap.exe" InstallDir: "C:\Garmin\Maps\OSM-AllInOne-EU-basemap" Section: "MainSection" ->(SectionMain) SetOutPath: "$INSTDIR" File: "osmmap.img" 16384 bytes File: "osmmap_mdr.img" 132378624 bytes File: "osmmap.mdx" 3638 bytes File: "basemap.TYP" 61231 bytes File: "osmmap.tdb" 45566 bytes File: "63240023.img" 675328 bytes File: "63240024.img" 10811904 bytes File: "63240025.img" 5993472 bytes File: "63240026.img" 6834688 bytes File: "63240027.img" 4183552 bytes File: "63240028.img" 9508352 bytes File: "63240029.img" 10859008 bytes File: "63240030.img" 3667968 bytes File: "63240031.img" 6547968 bytes File: "63240032.img" 5912064 bytes File: "63240033.img" 3705856 bytes File: "63240034.img" 4678144 bytes File: "63240035.img" 5473792 bytes File: "63240036.img" 7953920 bytes File: "63240037.img" 7333888 bytes File: "63240038.img" 4406784 bytes File: "63240039.img" 5394432 bytes File: "63240040.img" 4587520 bytes File: "63240041.img" 4775936 bytes File: "63240042.img" 2204672 bytes File: "63240043.img" 2920960 bytes File: "63240044.img" 2246144 bytes File: "63240045.img" 2904064 bytes File: "63240046.img" 3636736 bytes File: "63240047.img" 3557376 bytes File: "63240048.img" 4887040 bytes File: "63
Re: [mkgmap-dev] a FIXME map style
2010/3/29 maning sambale : > I can't find a worldwide data dump. But here's a sample in my area: > Hi, I asked the author of the keepright project and he gave me a database dump. He will try to make it public available as soon as he can, but first he will do some changes and his server is not good enough. So he will possibly change to dev.openstreetmap.de. I took the dump he gave me and wrote a sed-skript to parse this stuff and made a osm-xml file. Yes, I know, sed looks ugly but it is faster than the other stuff I tried. You can find the keepright-dump that I had (it is from 29. March), the converted osm-xml created from the dump and the bash skript that converted it here: http://dev.openstreetmap.de/aio/keepright_experimental/ Now the next step is to create an mkgmap stylefile and a corresponding typfile that matches the tags in the converted dump file. I would suggest to name it keepright_style and the typfile keepright.TYP It would be nice if somebody could do that. I simply don't have the time and enough knowledge about keepright to do that good. I think on a garmin map you don't need every kind of error from keepright. Only some of them can be corrected by viewing the reality outside. For example I usually don't care about data errors like duplicated nodes etc. while I am mapping outdoors. By the way I don't know if we could take the whole europe dump and make one tile or if we have to split it first. I think to develope the styles you could start with a smaller area (you can use osmosis to cut a bounding box of your choice or if you have enough memory and time ;) you can do it with josm). I think it is clear but please be carefull and do not upload this data to the osm database! So, now have much fun. *g* Thanks! Christoph ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
WanMil schrieb: > Hi, > > sometimes I create a map that colours the streets depending on their > maxspeed tag. I have attached the mkgmap style files and the typ file. > > It's quite simple but it's a good overlay if you want to see which > streets have which maxspeed taggings. > Hey cool, this one looks great! I would like to build a new maxspeed layer in the all in one garmin map with your styles. So I added it to my git stylefile repository. git clone git://github.com/aiomaster/aiostyles.git Can you tell me if you change something? I would like to be up to date ;) Thanks Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
2010/3/29 maning sambale : > Keep right provides GPX and RSS, but I'm not sure for a data dump > similar to OSB. GPX is much better because it is just xml. It is easier to convert to osm-xml. Or is mkgmap able to read GPX directly? But it is not necessary, because we can try to convert it with gpsbabel to osm-xml. How big is the world dump of keepright and where can I download it? Christoph ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
2010/3/29 maning sambale : > Cristoph, > > I was about to send you a separate mail. :) > > Anyway, I'm copying your fixme and osb style as my starting point. > Can you guide me through the OSM extract and conversion for my > specific area (the instructions are in German)? Yeah sorry, I was just too lazy to translate the stuff in english. Besides the german instructions are not so up to date... > I suggest you add keep right reports similar to OSB. > Ok, I try to tell you very short how I build the openstreetbugs-layer: First I download the Openstreetbugs daily SQL-Dump: wget http://openstreetbugs.schokokeks.org/dumps/osbdump_latest.sql.bz2 Then I convert it to osm-xml. You can find more details (in english) here: http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map#Openstreetbugs The conversion goes like: bzcat osbdump_latest.sql.bz2 | osbsql2osm-0.3/src/osbsql2osm > osbdump.osm Then I have to filter all interesting open bugs for a specified area with osmosis. osmosis --rx osbdump.osm --bb $(BBOX) --nkv keyValueList="type.0" --wx osb.osm To get the correct BBOX I just look into the osm extract from geofabrik and parse the tag with sed. Last step is to convert it with mkgmap and include the typfile: java -ea -jar mkgmap.jar --family-id=2323 --product-id=42 --family-name=osb --description='Openstreetbugs' --draw-priority=23 --style-file=styles/osb_style osb.osm osb.TYP Thats it. The question is, what is the input format of the keep right data? Can we do it similar and convert it to osm-xml data, and then create the garmin map with mkgmap? I didn't work with keepright before. Christoph ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a FIXME map style
2010/3/29 maning sambale : > Hi, > > Just got this idea of creating Garmin maps designed for fixing the > data (I use Garmin primarily to collect and fix OSM). Some have > started doing this like the nonames style and the All in One Garmin > (http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map#Openstreetbugs), > but I hope to expand the style to include all the QA tools available > in OSM. Some data/style we can integrate are: > > * No name roads (use the noname style) > * Openstreetbug reports > * Keep Right reports > * POI with names but no other tags > > Anyone doing a similar map? Maybe you can share some tools. > Hi, I make the Garmin All in One Map and your suggestion sounds very cool. Do you want to help me to make the fixme-layer better? At the moment you can see unnamed residentials and note-tags with this layer. Thats not so much. But we could integrate all the other fixme-stuff. I thought it is cool to have a git repository for working together at the mkgmap styles. You can get it here: git clone git://github.com/aiomaster/aiostyles.git If you have a solution to build this fixme stuff for garmins I would be glad to integrate it and update the styles and my build process. Thanks! Christoph ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Using multiple TYP files
2010/3/22 Toby Speight : > / > | $(MKGMAP) --gmapsupp \ > | --family-id=1672 --product-id=1672 1672*.img 1672.TYP \ > | --family-id=6324 --product-id=6324 6324*.img 6324.TYP > \ > How best to combine the two? Do it sequentially. $(MKGMAP) --gmapsupp --family-id=1672 --product-id=1672 1672*.img 1672.TYP mv gmapsupp.img gmapsupp1.img $(MKGMAP) --gmapsupp --family-id=6324 --product-id=6324 6324*.img 6324.TYP mv gmapsupp.img gmapsupp2.img $(MKGMAP) --gmapsupp gmapsupp1.img gmapsupp2.img Then you get a gmapsupp.img that contains what you want. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] process same input data with mkgmap with different styles at the same time
Hello list, I try to make Garmin maps with different layers. http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map The idea is, that you can enable or disable some transparent maps that you won't see. For this reason I use mkgmap with different options and stylefiles multiple times on the same input data: java -ea -jar mkgmap.jar [options1] --style-file=style1 input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 input_data java -ea -jar mkgmap.jar [options3] --style-file=style3 input_data ... This works good, but is not with so good performance as it could be. The input data are gzipped osm-tiles of europe and everytime mkgmap runs it has to decompress and parse the same stuff. The cleverst solution I could imagine is to start mkgmap once and give it different options at the same time for different threads for example: java -ea -jar mkgmap.jar [options1] --style-file=style1 --outputdir=dir1 [options2] --style-file=style2 --outputdir=dir2 [options3] --style-file=style3 --outputdir=dir3 input_data The question is: How difficult is it to implement in mkgmap? I looked at the source code but didn't understand enough to implement it. In germany we would say I looked at the code like a pig at a clockwork. ;) I think a problem is that at the moment the order of commandline args doesn't matter but then it would be important which option belongs to which thread. Maybe another solution could be to build a cache - like the tilesplittercache, where mkgmap can store the parsed input_data. Another mkgmap instance could use this cache instead of the input data. Maybe this solution would be more easy to implement or am I wrong? So something like: java -ea -jar mkgmap.jar [options1] --style-file=style1 --write-cache=cachdir input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 --read-cache=cachdir java -ea -jar mkgmap.jar [options3] --style-file=style3 --read-cache=cachdir What do you think about that ideas? Btw: Can I specify an output directory for mkgmap or is it everytime the actual directory? Thanks! Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter patch for enabling uncompressed tile outputs
Hello list,
I wanted to test some performance issues with splitter and so I needed to
switch of the gzip compression of the output tiles.
Based on a patch that Thilo Hannemann wrote in may last year I made a new patch
for the latest splitter version now.
Please can somebody submit this patch to the splitter svn? Maybe other people
need this, too.
You can give a commandline switch like
splitter.jar --uncompressed
or
splitter.jar --uncompressed=true
to switch of the compression for the output tiles. Default is to compress.
Thanks!
Christoph
Index: src/uk/me/parabola/splitter/args/SplitterParams.java
===
--- src/uk/me/parabola/splitter/args/SplitterParams.java (Revision 105)
+++ src/uk/me/parabola/splitter/args/SplitterParams.java (Arbeitskopie)
@@ -63,4 +63,7 @@
@Option(description = "Don't trim empty space off the edges of tiles.")
boolean isNoTrim();
+
+ @Option(description = "Don't gzip output tiles if --uncompressed is given.")
+ boolean isUncompressed();
}
Index: src/uk/me/parabola/splitter/Main.java
===
--- src/uk/me/parabola/splitter/Main.java (Revision 105)
+++ src/uk/me/parabola/splitter/Main.java (Arbeitskopie)
@@ -77,6 +77,8 @@
// Set if there is a previous area file given on the command line.
private AreaList areaList;
private boolean mixed;
+ // The option "--uncompressed" will turn off compression of the output data.
+ private boolean uncompressed;
// The path to the disk cache. If this is null, no cache will be generated or used.
private String diskCachePath;
// Whether or not a new cache needs to be generated.
@@ -215,6 +217,7 @@
geoNamesFile = params.getGeonamesFile();
resolution = params.getResolution();
trim = !params.isNoTrim();
+ uncompressed = params.isUncompressed();
if (resolution < 1 || resolution > 24) {
System.err.println("The --resolution parameter must be a value between 1 and 24. Resetting to 13.");
resolution = 13;
@@ -341,7 +344,7 @@
for (int j = 0; j < currentWriters.length; j++) {
Area area = areas.get(i * maxAreasPerPass + j);
currentWriters[j] = new OSMWriter(area);
-currentWriters[j].initForWrite(area.getMapId(), overlapAmount);
+currentWriters[j].initForWrite(area.getMapId(), overlapAmount, uncompressed);
}
System.out.println("Starting pass " + (i + 1) + " of " + passesRequired + ", processing " + currentWriters.length +
@@ -431,7 +434,11 @@
w.println("# description: OSM Map");
else
w.println("description: " + a.getName());
- w.format("input-file: %d.osm.gz\n", a.getMapId());
+ if (uncompressed) {
+w.format("input-file: %d.osm\n", a.getMapId());
+ } else {
+w.format("input-file: %d.osm.gz\n", a.getMapId());
+ }
}
w.println();
Index: src/uk/me/parabola/splitter/OSMWriter.java
===
--- src/uk/me/parabola/splitter/OSMWriter.java (Revision 105)
+++ src/uk/me/parabola/splitter/OSMWriter.java (Arbeitskopie)
@@ -34,16 +34,26 @@
this.bounds = bounds;
}
- public void initForWrite(int mapId, int extra) {
+ public void initForWrite(int mapId, int extra, boolean uncompressed) {
extendedBounds = new Area(bounds.getMinLat() - extra,
bounds.getMinLong() - extra,
bounds.getMaxLat() + extra,
bounds.getMaxLong() + extra);
- String filename = new Formatter().format(Locale.ROOT, "%08d.osm.gz", mapId).toString();
+ String filename;
+ if (uncompressed) {
+ filename = new Formatter().format(Locale.ROOT, "%08d.osm", mapId).toString();
+ } else {
+ filename = new Formatter().format(Locale.ROOT, "%08d.osm.gz", mapId).toString();
+ }
try {
FileOutputStream fos = new FileOutputStream(filename);
- OutputStream zos = new GZIPOutputStream(fos);
+ OutputStream zos;
+ if (uncompressed) {
+zos = fos;
+ } else {
+zos = new GZIPOutputStream(fos);
+ }
writer = new OutputStreamWriter(zos, "utf-8");
writeHeader();
} catch (IOException e) {
signature.asc
Description: OpenPGP digital signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Process for Creating Contour Maps?
Christian Gawron schrieb: > there are two different approaches: > - Using srtm2osm to generate contour lines as osm files. > - Using mkgmap to generate the contour lines directly. > There is another one. Somebody has wirtten a little Python-tool to convert srtm files to osm - data files which can be processed with mkgmap. It is called Phyghtmap. http://wiki.openstreetmap.org/wiki/Phyghtmap It is much faster on a multicore processor than srtm2osm because it tries to use multiple threads. Best wishes Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas behaviour
Thilo Hannemann schrieb: > The reason why you need a matching polygon rule for POIs to be generated is > that mkgmap needs this to find out that it is a polygon. > Now I really understand the problem. Would it be enough for mkgmap to specify a rule in polygons-file like this: building=* without any actions and typemappings, just to find out that building is a polygon tag and get a point out of it? signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas behaviour
Felix Hartmann schrieb:
> Well you might not like to have a POI for every polygon (what's the
> point in a POI for a city? - cities are entered as seperate points anyhow)
Ok, I see there are problems. But I thought that there is an algorithm to
check, if there exist a point in the polygon, yet to avoid double points for
the same thing.
> There is absolutely no reason why a POI should be in the middle of a
> Polygon.
It is easy and a good approach.
> It would be stupid to say because we have a city boundary, we
> don't need a city POI in Openstreetmap. For a building you might want to
> have the POI at the entry, and not in the middle of the buidling, .
> It is impossible to know whether if there exists a POI inside a Polygon
> (it will be never checked, cause too much cpu cycles to do so) it should
> be printed nevertheless, or it shouldn't be printed on the map.
But I thought there is exactly such algorithm integrated in mkgmap. Did I've
seen ghosts?
But you are right, this would cost cpu cycles to do it. So I would suggest to
provide an extra-option to enable such behaviour.
> There are many many more cases where it is stupid to assume that one can
> simply assign a POI to a Polygon.
Ok, maybe it would be good to define it separately for each feature.
I could imagine something like:
polygons:
building=yes {makepoint} [0x13 resolution 20]
# or just:
building=yes {makepoint}
# if you need only a point but no polygon!
points:
building=yes [0x6402 resolution 24]
Then you should be able to give an extra-option like:
--add-pois-to-areas=check-existing-points
so no points where created for a polygon if there is a real OSM-point that
matches the rule (in our example building=yes)
Does it sound sensefull?
Christoph
signature.asc
Description: OpenPGP digital signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas behaviour
Felix Hartmann schrieb: > That's because it's only a dirty hack alltogether. It would be bit > cleaner if there was a seperate file inside the style-file where one can > specify the poi to areas keys. Currently mkgmap can only know what kind > of POI to create, if it also has a matching Polygon. That's as far as I > understood the principle. I think I don't understand the point. Why do I need a separate file? Why this is not just the following algorithm? if --add-pois-to-areas is set 1. look if there is a matching polygon rule, make a polygon of specified type 2. independent if there was a polygon rule, look if there is a point rule for this tag and create a point of specified type if so > Even with a seperate file it would still be a > rather dirty hack, as it would be much better to have the POI inside > openstretmap at first hand. I don't really think it is good style to map > POIs for areas. No, I disagree. If you map a POI as polygon in Openstreetmap there is enough information for a later renderer to get a point out of this if needed. Why should I map an additional point in OSM? That would only increase redundancy and brings not more information. > Maybe a better solution would be to not create a poi, > but just match in the search indexes (but I don't know if that is > possible, I deem this to be impossible). I haven't seen yet, that garmin supports searching of areas, but I don't know enough about that. Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --add-pois-to-areas behaviour
Hi list, I found an issue with the --add-pois-to-areas option and don't know if it's a bug or a feature. Areas get only converted to points, if there is a matching rule in the points-style file AND if there is a matching rule in the polygons file. I don't understand the second condition. Imagine I want to show buildings only as a single point and no area. So it would be very useful to get building polygons converted to a point without specifiing it in polygons file. The dirty hack at the moment is to specify a rule in polygons and make the whole area transparent with a typfile, just to get a point created. But this is really stupid, because the polygon exist and the mousepointer could not show what is under this area. Can somebody help me? Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] how to get --generate-sea working?
Mark Burton schrieb: > Christoph, > > Further investigation shows no gaps in the coastline so the close-gaps > option is probably not doing anything useful in this case. > > I know the coastline was bad a few days ago because I tried to make a > map with sea then and it didn't work but that's been fixed now. > > One other thing, make sure that the drawing order for your sea and land > polygon types is correct otherwise the sea and the land will be drawn > in the wrong order. Hey, thank you very much! I got it! But do you know, what the garmin default colors are for land and sea in night and day mode? Now I have to choose it and I want it too look not too different from the default. Thanks! Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] how to get --generate-sea working?
Hello list, I am the developer of the All in one Garmin map. http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map At the moment I try to make some garmin maps for haiti with mkgmap. I use the geofabrik-extrakt of Haiti: http://labs.geofabrik.de/haiti/latest.osm.bz2 The Problem is, that I am not able to make the damn sea blue! Yes, I have read many many threads from this list about the generate-sea option, but things change rapidly and threads get really long. I thought that I understand how the different options work, but I am still not able to get this sea stuff to run. I use the latest mkgmap svn version. I used --generate-sea=extend-sea-sectors and defined a rule in polygons-style-file: natural=sea [0x32 resolution 10] But it doesn't work for Haiti. So I give the --generate-sea=polygons,extend-sea-sectors a try, and added a natural=land [0x27 resolution 10] rule in polygons file. I mapped a color with my typfile to this garmintype. But again - I couldn't get it to work. I really don't know what the problem is. The ocean looks like land. Please can somebody help me and tell me what to do to use the --generate-sea stuff correctly with haiti extract? Thank you! (And yes - I checked, that the whole coastline is present in the osm-file!) Christoph Sorry for my bad english... signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Mkgmap complains about '&' in role id
Lambertus schrieb: > Thanks for having a look at it. > > Well ofcourse it's a crappy mapped way and the busroute is mapped wrong, > but that should not make Mkgmap complain though ;-) > > Now that you've posted the XML from the API, it shows that this is > actually caused either by Splitter or Translit because the source osm > file used by Mkgmap shows the '&' only (not '&'). > > I'll do some tests to see where the '&' turns into '&' in my > toolchain, but that'll have to wait until tomorrow evening. Which Version of splitter do you use? The bug was fixed in version 103. Do you use an older version? signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-poi-to-areas customization?
Ben schrieb: > Hi guys, > > whilst its a great feature for some areas such as shops, its rather > useless for others, such as natural=rock, where there might be areas and > POIs tagged with. > Is there a way to have POIs generated from the areas for certain > polygons only? > And is there a way to generate a point from an area without having a rule in polygons file, just by having a rule in points file? Thanks Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1409: Add support for generating multiple map objects from a single OSM object.
svn commit schrieb:
> Version 1409 was commited by markb on 2009-11-27 20:52:16 + (Fri, 27 Nov
> 2009)
>
> Add support for generating multiple map objects from a single OSM object.
>
> The style system is augmented with 'continue' and 'stop' commands that
> can be used in style rule files to facilitate the generation of more than
> one map object (line or POI) from a single OSM object.
>
Sounds very cool. Can you give a full example how to use the continue and stop
commands, please?
Is it something like this or am I wrong?
Imagine there is a node tagged with amenity=restaurant and tourism=hotel and
I'd like to have 2 nodes in Garmin map.
amenity=restaurant {continue} [0x2a00 resolution 24]
tourism=hotel {stop} [0x2b00 resolution 24]
Thanks
Christoph
signature.asc
Description: OpenPGP digital signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter produces invalid xml
Hello list,
I fixed the character escaping bug in splitter. I have no access to svn, so
please can somebody check my changes and apply them, if they are correct?
Index: src/uk/me/parabola/splitter/OSMWriter.java
===
--- src/uk/me/parabola/splitter/OSMWriter.java (Revision 99)
+++ src/uk/me/parabola/splitter/OSMWriter.java (Arbeitskopie)
@@ -128,7 +128,7 @@
writeInt(m.getRef());
writeString("' role='");
if (m.getRole() != null) {
-writeString(m.getRole());
+writeAttribute(m.getRole());
}
writeString("'/>\n");
}
@@ -158,6 +158,8 @@
writeString("&");
} else if (c == '<') {
writeString("<");
+ } else if (c == '>') {
+writeString(">");
} else
writeChar(c);
}
signature.asc
Description: OpenPGP digital signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter produces invalid xml
Hello list, I found a bug in splitter, but don't know how to fix it. The problem is the following: There is a way, that is member of a relation and has special characters in its role-tag. Look here: http://www.openstreetmap.org/browse/way/26683153 The role tag in the osm-data, which I get from the Api is: role='<->' Ok, now I use the splitter and just try to split this file. The role-tag changes: role='<->' and so it's just invalid xml and mkgmap dies with a bad-file-format error. Can anybody explain the problem here with splitter? Why does it change the escaped characters and unescapes them? I use the latest splitter version from svn. Thanks Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas and adress problems
Christoph Wagner schrieb:
> Hello list,
>
> I just want to produce a garmin map, where you can see all adresses
> tagged in osm, even the adresses on a building polygon for example too.
>
> So I used the --add-pois-to-areas option and wrote just one line in the
> points style file:
> addr:housenumber=* {name '${name} (${addr:street} ${addr:housenumber})'
> | '${addr:street} ${addr:housenumber}'} [0x7100 resolution 24]
>
> I hoped that there would be nodes at the place of building-polygons
> tagged with adresses but it isn't so.
> I can see just the nodes that were tagged as nodes.
>
> What is the problem? Does the --add-pois-to-areas option ignore adress
> information? Is it possible to change that in a way?
>
> Thanks and sorry for my bad english...
> Christoph
>
I found out, that if there is no rule for the adress tag in polygon
stylefile the polygon wouldn't be evalueted for conversion to a single
point.
As the option --add-pois-to-areas implies the poiType should be set also
according to point-rules even for polygons, because they might be
converted to points but will not be examined, since they dont have a
polygon rule.
That is why you will see a P rendered in a parking area only if you also
have a rule that include parking areas in the polygons stylefile.
For housenumbers I'd like to have ONLY the collapsed points in the
garmnin map and not the house polygons themselfs.
Thanks
Christoph
signature.asc
Description: OpenPGP digital signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --add-pois-to-areas and adress problems
Hello list,
I just want to produce a garmin map, where you can see all adresses
tagged in osm, even the adresses on a building polygon for example too.
So I used the --add-pois-to-areas option and wrote just one line in the
points style file:
addr:housenumber=* {name '${name} (${addr:street} ${addr:housenumber})'
| '${addr:street} ${addr:housenumber}'} [0x7100 resolution 24]
I hoped that there would be nodes at the place of building-polygons
tagged with adresses but it isn't so.
I can see just the nodes that were tagged as nodes.
What is the problem? Does the --add-pois-to-areas option ignore adress
information? Is it possible to change that in a way?
Thanks and sorry for my bad english...
Christoph
signature.asc
Description: OpenPGP digital signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Problems with boundaries and multipolygons
Hello list, I tried to build a garmin map with the boundaries from osm. But with the newest mkgmap version there are some problems. In the result some boundary ways are just missing. With an older mkgmap version (I think older than the merge from the multipolygon branch - I tried 1133) everything works fine. I think the problem has to do with boundary relations that were in germany tagged with: type=multipolygon boundary=administrative but the members of these relations are often not closed ways and so I think mkgmap produces wrong output. Is it possible to deactivate the new handling of multipolygons on the commandline until there is a fix? Can somebody confirm this bug? Thanks Christoph signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] complete list of all mkgmap options
Hello list, I searched for a complete list of all mkgmap command-line options and what they should do, but I couldn't find a good and up-to-date list. The list in the wiki is much too old. In the last few month they were very cool and usefull improvements of mkgmap but it's sometimes not easy to use and test them because they are not known. I would wish to have a Wiki page with all mkgmap options, their functionality, their usage and their status (stable, unstable...). Do you think this is a good idea? Where can I find a list of the options to fill the wiki page? Thank you and have a nice day! Christoph from Dresden signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
