Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Importing one OSM pbf file overwrites or disables the last pbf that was uploaded
I was getting annoyed at the old OSM tiles that were available directly through YAAC so I started downloading entire U.S. states via Geofabrik. First problem I noticed is that when I imported my Yukon pbf, YAAC seemed to not show any mapping data that I already had downloaded in the way of tiles. When I then imported the Alaska pbf the Yukon went away. This behavior was not expected as I would have assumed these pieces to have fit together instead of one being thrown out for the other. Is this a bug or am I missing something here?
73, Eric WG3K |
How old were the old tiles? :-) I admit, I haven't posted any updates since September. However, I just finished processing the December 16th snapshot of the OpenStreetMap database and will be posting that to my website tonight.
Your comment about old tiles getting flushed is unfortunately a design feature of the YAAC OSM preprocessing importer code. It replaces any 1x1-degree square tile with the new data for that tile in the input .pbf or .osm.bz2 file. So, if you are going to do partial segments of the world map, I recommend getting an export that is axis-aligned to whole degree boundaries (for example, -100 to -90 degrees longitude, +20 to +30 degrees latitude), rather than bounded to higgly-piggly political or geographical borders. It can't merge two files together because it is possible for a Way (polyline) to exit and reenter a 1-degree square tile, such that there are two Ways in the same .ways file with the same identifier (different pieces of the Way). The importer wouldn't know which ones of the old file versus the new file to keep (it is possible for OpenStreetMap editors to remove obsolete map features), so it just discards the old tile file entirely and replaces it with the new one for that tile based solely on the new input data. This is why I routinely import the whole planet dataset in one giant lump. The last run took me not quite 22 hours to process (on a fairly high-powered gaming system), and will take another hour to compress the individual tile files for more efficient network transfer for other users. Sorry about the bad news. Andrew, KA2DDO author of YAAC |
-‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, December 20, 2019 9:55 PM, Andrew P. <andrewemt@...> wrote: How old were the old tiles? :-) I admit, I haven't posted any updates since September. However, I just finished processing the December 16th snapshot of the OpenStreetMap database and will be posting that to my website tonight.They were the ones from September. I'm an OSM contributor so I like to be able to see my contributions (fixes and such) a lot sooner than a few months. :) Your comment about old tiles getting flushed is unfortunately a design feature of the YAAC OSM preprocessing importer code. It replaces any 1x1-degree square tile with the new data for that tile in the input .pbf or .osm.bz2 file.Hmmm... Yeah, I can see what's going on there. So I should be downloading more data than I am instead of trying to stitch together smaller pieces. This is why I routinely import the whole planet dataset in one giant lump. The last run took me not quite 22 hours to process (on a fairly high-powered gaming system), and will take another hour to compress the individual tile files for more efficient network transfer for other users.I always wondered how long it would take to process the entire globe's worth of data. I wonder if you were to process the daily diffs if it would take a vastly shorter amount of time and could keep the tiles up to date for everyone. 73, Eric WG3K |
开云体育The Dec 16th OpenStreetMap snapshot is now available for download. The annoying thing is, I processed other sets since September, but forgot to copy them over to the webserver. How embarrassing.
-------- Original message --------
From: "Eric H. Christensen via Groups.Io" <eric@...> Date: 12/21/19 00:11 (GMT-05:00) To: [email protected] Subject: Re: [yaac-users] Importing one OSM pbf file overwrites or disables the last pbf that was uploaded -‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, December 20, 2019 9:55 PM, Andrew P. <andrewemt@...> wrote: > How old were the old tiles? :-) I admit, I haven't posted any updates since September. However, I just finished processing the December 16th snapshot of the OpenStreetMap database and will be posting that to my website tonight. They were the ones from September.? I'm an OSM contributor so I like to be able to see my contributions (fixes and such) a lot sooner than a few months.? :) > Your comment about old tiles getting flushed is unfortunately a design feature of the YAAC OSM preprocessing importer code. It replaces any 1x1-degree square tile with the new data for that tile in the input .pbf or .osm.bz2 file. Hmmm...? Yeah, I can see what's going on there.? So I should be downloading more data than I am instead of trying to stitch together smaller pieces. > This is why I routinely import the whole planet dataset in one giant lump. The last run took me not quite 22 hours to process (on a fairly high-powered gaming system), and will take another hour to compress the individual tile files for more efficient network transfer for other users. I always wondered how long it would take to process the entire globe's worth of data.? I wonder if you were to process the daily diffs if it would take a vastly shorter amount of time and could keep the tiles up to date for everyone. 73, Eric WG3K |
to navigate to use esc to dismiss