[OSM-talk] JOSM plugin to import GeoJSON?

Jukka Rahkonen jukka.rahkonen at latuviitta.fi
Tue Mar 22 12:56:35 UTC 2016


Frederik Ramm <frederik <at> remote.org> writes:

> 
> Hi,
> 
> On 03/20/2016 10:56 PM, Stefan Keller wrote:
> > But Shapefile remains an oldtimer with more drawbacks than limited
> > field names; see [1].
> > GeoJSON (ascii) and GeoPackages (binary) are formats which are more
> > suited for the job.
> > I still have hope that JOSM will be able to read those vector formats too.
> 
> Frankly, whenever I venture into the brave new world of Spatialite, I
> come back to good old shape files after a while for performance reasons.
> I'm not sure if Geopackage has significant performance improvements over
> simple Spatialite but if it hasn't then my recommendation for simple GIS
> processing is certainly to stick with shape files for the time being -
> despite all their shortcomings.


Hi Frederic,

I would like to receive some sample data, exact way to reproduce some of
your ventures and cold numbers about the speed you have experienced.
Spatialite does have it's limits but for plain selects with spatial and
attribute filters it can well outperform both shapefiles and PostGIS. 

I keep most vector data for WMS services in Spatialite or GeoPackage due to
the already mentioned and some other reasons:
- supports long attribute names
- supports strings longer than 255 characters
- supports SQL
- supports attribute indexes
- much less encoding problems due to UTF-8
- one single file vs. a bunch of files in shapefile, perhaps even split to
separate bunches for points, lines and polygons.

For me SpatiaLite is a little bit slower than shapefiles if only spatial
filter (BBOX) is used but usually faster if also attribute filters are
involved, especially if more than one field is needed in filters (Shapefiles
can be sorted by one attribute only). Of course spatialite must have indexes
which suit the queries and when it comes to spatial index, the client must
know how to utilize the table based R-Tree index. I also recommend to VACUUM
once the database is ready to use.

Many spatial operations are relatively slow in Spatialite and I don't
usually utilize them on-the-fly with WMS server. Instead, I run the
algorithm once and store the result into a new table because a few
mega/gigabytes of additional disk space is not crucial on the server. 
However, such operations tend to be slow also if shapefiles are used as
source data.

Write performance especially with concurrent writes is another story. I am
talking about read-only operations. I know that I am writing empty words as
far as I do not include reproducible facts but I am willing to join to a
controlled test if someone is organizing such.

-Jukka Rahkonen-






More information about the talk mailing list