On 19.01.18 01:53, Paul Norman wrote:
Speaking as a developer and frequent consumer of OSM data, don't do
any of these things to save space.
Instead, worry about ease of editing. If a few meter long way has
hundreds of nodes, that's a problem for editing, and should be fixed;
a mass of unnecessary import-sourced tags confuses people, don't use
them; and overlapping landuse with lots of multipolygons is difficult
to edit, so should be avoided. Following these behaviors will slightly
reduce data size, but the point is keeping the map maintainable.
It's also difficult to say what will affect size without a detailed
understanding of the format and how it's processed. Size is also not
the only indicator of time to process - for various reasons, relations
are much slower to work with than ways with most data consumption
workflows.
I've met multipolygons which are hard to understand. It is similar here
with the programming code, it should be first of all readable, otherwise
if the developer disappears due to a bus factor [1], it would be hard to
maintain.
Certainly, throwing hardware at the problem is a perfectly respectable
solution. However, if we look at the power consumption of modern
processors it ceases to look perfect. For example, Intel i7-8700K 3.7
GHz 8th generation processor consumes 95 W [2], add to this the fans,
hard disks, etc., it comes to 400 W power supply unit. And it did not
change from, for instance, 4th generation processors, which also had
power consumption of 60 - 90 W [3].
For comparison, the Raspeberry Pi 3 single-board computer requires only
10 W power supply [4], 40 times less. And this single-board computer
with the Raspbian Lite GUI-less OS is still capable to run an Apache2 &
database web-server for a simple site with a light traffic.
So keeping the map maintainable, correcting polygon or tagging errors,
avoiding unnecessary import-sourced tags and nodes functions as a
precalculation, which is done only once and by this reduces waste
multiple times.
[1] https://en.wikipedia.org/wiki/Bus_factor
[2] https://www.brack.ch/intel-cpu-core-i7-8700k-3-616011
[3] https://www.brack.ch/intel-cpu-core-i7-4790k-4-307846
[4] https://www.raspberrypi.org/products/raspberry-pi-3-model-b/
Best regards,
Oleksiy
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
