[OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Darafei "Komяpa" Praliaskouski]

Hi,

Please don't try to save on keeping data in text format, this is a path to
removing source= tags and starting to use abbreviations in name for the
sake of file size, ignoring the fact that each object has much longer
iso8601 timestamp attached to it.

Use proper format, like .osm.pbf, that employs text strings compression,
binary representation of everything numeric and fixes the issue of 'spaces
around country code' and 'www.' by GZIPing the contents.

чт, 18 янв. 2018 г. в 14:03, Oleksiy Muzalyev <oleksiy.muzalyev at bluewin.ch>:

> On 18.01.18 06:58, Mark Wagner wrote:
> > On Thu, 18 Jan 2018 06:14:17 +0100
> > Oleksiy Muzalyev <oleksiy.muzalyev at bluewin.ch> wrote:
> >
> >> Good morning,
> >>
> >> I started to experiment with the OSM data [1] on a local computer,
> >> and I begin to realize how big these data files are. It takes quite a
> >> while to load into the local database just the data for one country.
> >>
> >> What can I as a map editor do to keep these data files to a
> >> reasonable size without compromising  data quality? I mean in the
> >> sense, - take care of the pennies and the pounds will take care of
> >> themselves?
> >>
> >> I could think of the following three approaches so far:
> >>
> >> - using as short an URL as possible, website=http://somewebsite.com
> >> instead of website=http://www.somewebsite.com , three characters
> >> less; [2]
> >>
> >> - correct phone number ISO format, phone=+12 345 678 90 12 instead of
> >> phone=+12 (345) 678 90 12 , two characters less;  [3]
> >>
> >> - deleting unnecessary nodes from a way (Shift-Y in JOSM) with
> >> consequent verification of its geometry;
> >>
> >> What else, if anything, could be done?
> > Honestly, the best thing you can do is not worry about it.  The world
> > is a big, complicated place.  The three bytes you save from shortening
> > a URL?  You'd need to repeat it 400 times to fit one extra gas station
> > on the map.
> >
> > As an experiment, I tried applying various data-saving
> > options to a park I've mapped.  I managed to reduce the size from
> > 1240354 bytes to 1218966 bytes for a savings of 1.7% -- savings that
> > will vanish almost instantly this spring once I resume mapping
> > seasonal wetlands.
> >
> Mark,
>
> You make sound 1.7% as not much, however, in say civil aviation or
> maritime industries, consistent 1.7% of fuel efficiency increase would
> be a breakthrough.
>
> I do not suggest, speaking figuratively, not breathing to save air. On
> the contrary, I think the mapping just begins, at least in some areas.
> So there will be much more, perhaps, times more data.
>
> At the same time, it would not harm to be mindful of data size issue and
> to follow simple best practices, as the shortest URL possible, the ISO
> phone format, etc.
>
> Best regards,
> Oleksiy
> osm: Alex-7
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20180118/71b2611b/attachment.html>