Hi,
How it could be done (using another (maybe self-written) tool):
A database would make sense for saving changes to the map.
One or several processes would be running then on this db and searching
for areas with the highest priority. (maybe a main process that
distributes the areas that need to be changed to the other threads.
The priority would be represented by the number of changes made in one
area and by the age of the oldest change.
The db would have an entry for each image of the world.
The db has the columns: lat lon width/height oldest_change number_of_changes
A query would sort the db by "number of changes" and as a second
criterium "oldest_change".
If the backup gets too big one day "oldest_change" could be further
prioritized
For example by starting a cronjob on a daily/weekly basis, that sorts
the db only by "oldest_change".
One step that updates one image updates it's 8 surrounding images (if
neccessary) as well to improve overlapping glow (if the new system uses
the same design as the old one).
The question is: is there a better way for the generation itself to get
the information where reports have been collected?
Ideally it needs to be a db, because then a simple query collecting at
least one entry from the db in a lat/lon range would be enough to know
that a dot needs to be placed at some space.
Or you could use the range of the image to get all reports, though that
could be too many. I don't know.
Another thing is, I don't know whether there is a good way to even
access the db (because it's archived on on the amazon servers).
One thing I also thought about is:
Why should we even create images lower zoom levels based on the db?
Wouldn't it be easier to simply combine the higher zoom level pictures
to get the bigger ones?
The algorithm for combining images is probably way faster anyways than
creating new images (this should be tested beforehand).
And it would also look better if you zoom in on the map, because there
wouldn't be any differences between lower and higher zoom levels except
the resolution.
In this case there would be one db for the lowest zoom level.
The width/height for the square would be always the same -> no
additional column needed.
The lat/lon coordinates would be the one of the top-left corner of the
area/image.
And the other db would be for collecting the amount of changes in the
lower resolution images.
They would have the columns: lat/lon, zoom_level, oldest_change and
number_of_changes
Images on lower zoom levels would only be updated once the images on
higher zoom levels that it relies on are new enough.
For each image on higher zoom levels: the number_of_changes needs to be
below a certain threshhold and the older the image is the higher is the
chance that it needs to be regenerated first.
Or for the lowest zoom levels there could be a cron job.
The lowest zoom level (global) could be generated only on a weekly basis
and so on.
This cron job would run a query for all images in the highest zoom level
first, generate the important missing images, then do the same query for
lower zoom levels again.
And something I wanted to know: Is this the technique Ichnaea is using
to get PNG 8 with an alpha transparency that is not simply using 1-bit?
http://www.sitepoint.com/png8-the-clear-winner/
Anyways, let me know what you all think.
Regards,
Felix/Djfe
_______________________________________________
dev-geolocation mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-geolocation
