Can't build pbfparser #199
Comments
|
After adding |
|
"OsmParser2" shouldn't be there, it was for something experimental which is no in the experimantal branch only. So I deleted it. |
|
I hope it's ok to revive this issue - the following error occurs using ** Update 1 ** ** Update 2 ** I stopped here, to be continued: ----- kind of off-topic ------- Btw, the
While the only choices on the SRTM download manager are:
So I guess this should be changed to |
|
uff, couple of issues.... for the compile error - my fault - just removed BPbfBlobDecoder2 from the repo - was left from an experimental POC Which pre-processor script are you using? The "process_pbf_planet_production.sh" is the original production script. As in your log The old one ("process_pbf_planet.sh") will most likely not work anymore after my changes to speedup the prepropcessor. So i propose to use the production script. But first remove the "osmupdate" part on the top, and the "scan_world" (=brouter-suspect-scan) and "traffic_simulation" calls. And if you need help tp get the SRTM data, contact me. Or start without elevantion data for a start. regards, Arndt |
|
Hi Arndt, looks good - a rd5 file was generated. I'll try to use it in BRouter later this day and let you know the outcome. Thanks a lot for the fast replies. Below the altered script I used to generate the rd5 file (maybe this saves others some time): |
|
I can confirm that the self-generated rd5 file works in BRouter and it contains height data. However: The height data for the same OSM nodes is different, see screenshot:
Thus, I'm wondering if you do pre-process the SRTM data before using it for the rd5 file generation? a) FOSSGIS 2014: Hysterese Filter on the 90M data b) FOSSGIS 2015, minute 19:40+: Noise-Filter new We might use high-res height data in our research project as we only test this in a small region where this data is available but I would need to know if the data we insert into the rd5 generation is altered before it's output again in the BRouter |
Hi Armin, I wasnt't aware there is a 30m update at CGIAR. And I just tried to download a file, but I got the 90m version. And I compared that with the one I downloaded years ago, and it differs: new download: 19.09.2008 15:05 2.479 readme.txt my version: -rw-rw-r-- 1 abrensch abrensch 2479 Sep 19 2008 readme.txt so they differ in size and timestamp. But readme says in both cases it's version 4.1
I'm still using 90m data. Never took the 30m data productive. Just could'nt prove that it actually gives better results. I do use a pre-processor, but this is just technical to have a compact binary format for speed parsing. I call it ".bef (brouter elevation format). But it does not apply any filtering. Actuall I developed the bef-format in order to be able to process 30m data.
Yes, hysteresis filter is done during routing.
For 90m, I use a simple linear interpolation between the 4 surrounding grid-points. For 30m, I developed the advanced filtering (but did not take it productive)
I also converted some lidar-data into the bef-format for >60 degree where srtm is not available. I could give a access to my cgiar-files or my .bef-files. Just send me a mail, so I can provide an access link to some files. I cannot do that publicly due to licence issues. regards, Arndt |
|
Hi Arndt, I'm trying to convert this DGM2 data (e.g. section 4005640) to the ArcInfo/ESRI ASCII format in order to use it with the mapcreation script. The data comes in 2 km x 2 km XYZ text files. I tried the following steps:
A) Now I'm wondering if I simply have to make sure the height-data area needs to match the shape of the CIGAR data (5*5 degrees)? I'm currently only using an area of ~ 10 km x 8 km of height data of inner Dresden region. B) Or if I missed an obvious step somewhere in the process. In the following picture you can see the CIGAR SRTM data (the outer, red data) and the converted DGM2 data (inner, black area) which I generated and tried to use:
|
not sure, really. Actually, I never used the asc/zip Parser for anything else then the 90 meter, 5 times 5 degrees, 6001 Though looking at the parser: Method "readFromStream" of https://github.com/abrensch/brouter/blob/master/brouter-map-creator/src/main/java/btools/mapcreator/SrtmData.java and the linear-interpolation formular: Method " getElevation" of https://github.com/abrensch/brouter/blob/master/brouter-map-creator/src/main/java/btools/mapcreator/SrtmRaster.java It should work if the header (rows/cols, lower left corner, cellsize) in your ASC really match the structure o your data. But my guess it that it does not match, the "interpolation" formular will happily extrapolate and you get nonsense results. |
|
Thanks a lot for pointing to the relevant Code sections, this helped. Using Looking into the generated .asc file itself confirms this: Thus, I'll use something like -999 as noDataValue to be within the And I'll either convert the |
|
Short update: Here is the script I used for conversion - maybe it safes others some time: I will probably also try to adjust the |
Sure you can adapt the parse to handle floating point. Then you proably also wnt to change the data-type of "eval_array", or at least move the "*4" multiplication from the interpolation code to the parser. Finally, for what's going into the rd5-files this is a "short" datatype with 25cm resolution. Pretty hard to change that. But 25cm more or less matches the accuracy of the data (15cm according to Landesvermessungsamt Sachsen), so it should be o.k.... |
@abrensch Could you please send me the download link for your cgiar files? I can then generate a rd5 file with the script posted above which imports the For others who want to use un-smoothened DGM2 data, this is why:
In the online version of the BRouter this problem does not occur, so I'll just use the height data from there for now: |
On Windows with JDK 8, following
mapcreation.mdguide I can successfully buildbrouter.jarbut when I try to buildpbfparserwithI get this error:
What could be the problem?
Sorry if it's a dumb question, Java is new for me.
Here's contents of brouter.jar:
The text was updated successfully, but these errors were encountered: