Hi all, I've committed r257. Changes since r254: - fixed memory leaks (appeared when more than max-areas tiles were processed). Now it shoud really require less memory if you lower the max-areas value so that multiple read passes are done (of course run time increases) - write areas.poly only if no split-file was given - don't write unneeded coordinates to areas.poly (filter points lying on a straight line) - correct handling of holes in polygon (experimental) - report number of "areas per pass" in problem-list-generator - increased allowed max-areas (now 4096) - increased default max-areas (now 512) If I don't get problem reports, this version will be merged to trunk next monday. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r257-tp5740402.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
will try it, please update the help file too! I think if you use --keep-complete, then you should not specify --overlap at all, right? Because on 256 I got crahes while using --keep-complete --overlap=0... which is however exactly what is recommended in the help file. I don't think there is any need for overlap if --keep-complete is used, or could there be reasons? Also I think most people will want --keep-complete by default, except if overlap is >0 could you further specify this please? I cannot see how to enable it (which I would expect if it is really experimental and not only new and needs to be tested). - correct handling of holes in polygon (experimental) On 14.12.2012 12:01, GerdP wrote:
Hi all,
I've committed r257. Changes since r254: - fixed memory leaks (appeared when more than max-areas tiles were processed). Now it shoud really require less memory if you lower the max-areas value so that multiple read passes are done (of course run time increases) - write areas.poly only if no split-file was given - don't write unneeded coordinates to areas.poly (filter points lying on a straight line) - correct handling of holes in polygon (experimental) - report number of "areas per pass" in problem-list-generator - increased allowed max-areas (now 4096) - increased default max-areas (now 512)
If I don't get problem reports, this version will be merged to trunk next monday.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r257-tp5740402.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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Felix Hartmann-2 wrote
will try it, please update the help file too!
Hmm, what help file? The wiki or something in the sources? Felix Hartmann-2 wrote
I think if you use --keep-complete, then you should not specify --overlap at all, right?
If you specify --keep-complete, the default for --overlap is 0. If you specify keep-complete with a non-zero value for overlap, you should see a warning. Felix Hartmann-2 wrote
Because on 256 I got crahes while using --keep-complete --overlap=0... which is however exactly what is recommended in the help file. I don't think there is any need for overlap if --keep-complete is used, or could there be reasons?
If you can reproduce the crash with r257, please send details how to reproduce it. Felix Hartmann-2 wrote
Also I think most people will want --keep-complete by default, except if overlap is >0
I did not dare to make it the default, but I agree that most people will want it. So, if I got you right, splitter should set keep-complete=true if user specifies neither overlap nor keep-complete=false ? Felix Hartmann-2 wrote
could you further specify this please? I cannot see how to enable it (which I would expect if it is really experimental and not only new and needs to be tested).
- correct handling of holes in polygon (experimental)
Well, the osmosis polygon file format allows to define areas with holes. I don't see any need for that, but I tried to make sure that nothing stupid happens if a user tries a poly file with hole(s). Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r257-tp5740402p5740415.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Felix Hartmann-2 wrote
Also I think most people will want --keep-complete by default, except if overlap is >0
I did not dare to make it the default, but I agree that most people will want it.
I'd support making it the default and even removing --overlap and any of the overlap code. Overlap is just an algorithm that doesn't lead to correct results except if the overlap is large enough, the difficult bit is improving on that without taking an unacceptable amount of time. So your work creating an algorithm that is accurate and yet still takes time in the same order of magnitude as the overlap method is rather an achievement. Overlap served us well for a time, but its going to get less and less useful as file sizes get larger and there are more and more large relations (which barely existed in the time of the first splitter). Splitter doesn't have to support more than one algorithm (we can always create old releases if really needed), but if it does the best one that is most likely to lead to correct results should be the default. ..Steve
Steve Ratcliffe wrote
I did not dare to make it the default, but I agree that most people will want it.
I'd support making it the default and even removing --overlap and any of the overlap code.
Overlap is just an algorithm that doesn't lead to correct results except if the overlap is large enough, the difficult bit is improving on that without taking an unacceptable amount of time.
So your work creating an algorithm that is accurate and yet still takes time in the same order of magnitude as the overlap method is rather an achievement.
Overlap served us well for a time, but its going to get less and less useful as file sizes get larger and there are more and more large relations (which barely existed in the time of the first splitter).
Splitter doesn't have to support more than one algorithm (we can always create old releases if really needed), but if it does the best one that is most likely to lead to correct results should be the default.
I already tried to make it the default, but I first have to understand the code that evaluates the parameters. I did not find a simple way to distinguish between "no parameter given" and "keep-complete=false" being used. Removing overlap is not needed reg. code complexity, since it just means to blow up a bbox. WanMil mentioned that it still might be needed to help his process-destination algorithm, so I prefer to wait until that's clear . Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r257-tp5740402p5740688.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, it doesn't belong to your improvements, but it's a think which might be confusing to new users. Splitter output in very beginning a list of parameters and the used values. This is a nice thing, but also very confusing, because there are displayed wrong things. Eg. if I set --split-file, max-nodes, mapid, no-trim and polygon-file aren't used by splitter (or I'm wrong?). So it shouldn't be displayed at all. In general it would be more clear, that only those parameters were displayed, which are really used (default values or set) for this splitter-run. This mustn't be fixed in your branch. It's just a general thought about it. Maybe others have a different view to it. Henning
Hi Henning, I absolutely agree. I've already tried to change that, but the parameter handling is a bit difficult to understand (for me) because the code is somehow self-generating. The problem was not that obvious until now because most parameters were independent from each other, but now a lot of things are somehow related. Maybe I'll have to rewrite that part... Ciao, Gerd Henning Scholland wrote
Hi Gerd, it doesn't belong to your improvements, but it's a think which might be confusing to new users.
Splitter output in very beginning a list of parameters and the used values. This is a nice thing, but also very confusing, because there are displayed wrong things. Eg. if I set --split-file, max-nodes, mapid, no-trim and polygon-file aren't used by splitter (or I'm wrong?). So it shouldn't be displayed at all.
In general it would be more clear, that only those parameters were displayed, which are really used (default values or set) for this splitter-run.
This mustn't be fixed in your branch. It's just a general thought about it. Maybe others have a different view to it.
Henning
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r257-tp5740402p5740450.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
If splitter output is going to be changed, I would also suggest to enable a --quiet / --verbose mechanism, so that those who don't understand most of the output meaning can omit it. Carlos El 14/12/12 19:30, GerdP escribió:
Hi Henning,
I absolutely agree. I've already tried to change that, but the parameter handling is a bit difficult to understand (for me) because the code is somehow self-generating. The problem was not that obvious until now because most parameters were independent from each other, but now a lot of things are somehow related. Maybe I'll have to rewrite that part...
Ciao, Gerd
Henning Scholland wrote
Hi Gerd, it doesn't belong to your improvements, but it's a think which might be confusing to new users.
Splitter output in very beginning a list of parameters and the used values. This is a nice thing, but also very confusing, because there are displayed wrong things. Eg. if I set --split-file, max-nodes, mapid, no-trim and polygon-file aren't used by splitter (or I'm wrong?). So it shouldn't be displayed at all.
In general it would be more clear, that only those parameters were displayed, which are really used (default values or set) for this splitter-run.
This mustn't be fixed in your branch. It's just a general thought about it. Maybe others have a different view to it.
Henning
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r257-tp5740402p5740450.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
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale LibreOffice desde http://es.libreoffice.org/descarga/ LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
If splitter output is going to be changed, I would also suggest to enable a --quiet / --verbose mechanism, so that those who don't understand most of the output meaning can omit it.
OK, I perfer to use java [options] -jar splitter.jar ... > splitter.log, but I add that to my todo list. The list looks like this now (no specific order), let me know when you like to add something: - optimize memory requirements in ProblemListHandling phase - try to optimize memory requirements in pbf and o5m writer - use thread(s) to interpret input file - limit generated problem list to ways and relations with type=multipolygon or type=restriction - report only those parameters that are in use, or report two lists, one with the user specified parms and one with those that are in use - add --verbose parm to suppress anything but errors or warnings in stdout. Gerd
participants (6)
-
Carlos Dávila -
Felix Hartmann -
Gerd Petermann -
GerdP
-
Henning Scholland -
Steve Ratcliffe