Re: [OSM-dev] Python XML Parser on Windows
Hi Spencer, I'd definitely recommend lxml: https://lxml.de/. One of the benefits of lxml is that it is cross platform. You can find Windows binaries for lxml and many other Python libraries here: https://www.lfd.uci.edu/~gohlke/pythonlibs/#lxml Regards, Frank On 07-08-2019 06:20, Spencer Gardner wrote: I'm sort of resurrecting an old thread I started last year. I find Martijn's Overpass Python library to be very useful for small queries but I frequently run into usage limits. I'd like to query an XML download directly to save bandwidth and reduce consumption of Overpass resources, but I can't find any suitable Python libraries that are WIndows-ready. Is there something I'm missing? Has anyone else found a solution that works? By way of example, Geoff Boeing's excellent osmnx package appears to use a home-grown OSM parser due to lack of a cross-platform option. https://github.com/gboeing/osmnx/blob/eebbca0ed1d59a6dfe07c90493d54c0beab45145/osmnx/utils.py#L1181 Thanks for any help ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.7+: Split node concept?
On 10-10-12 10:41 PM, Matthias Julius wrote Maybe less ugly would be to have nodes just contain lat and lon and introduce new point elements that need to reference a node. That would also make it easier to put two different objects at the same spot (like a mail box on a lamp post) as added benefit. +1 for such a separation of responsibilities of nodes and point features. IMO this would also be beneficial for line and polygon features. Features should be cleanly separated from their geometries, which is not currently the case. This can be done in such a way that the topological integrity remains intact. As proposed by Matthias, one point feature would reference one node. A linestring feature would reference one or more consecutive ways, whereas a polygon feature would reference one or more closed sets of ways (also called 'rings', one exterior, zero or more interior rings). Maybe geometric aggregates (set of disjoint geometries) should be allowed as well, either homogeneous (multipoint, multilinestring, multipolygon), or heterogeneious (multigeometry). That would be possible with this model as well. If this were to happen, it would also be easier to manage things like bridges and (simple) routes. Now it is too often necessary to chop up ways, use relations, etc., so that ways end up with a whole bunch of tags. I find situations like this difficult to manage. Probably there has already been plenty of discussion about this in the past, but I think it would be worthwhile to discuss this further for a future API version :) Frank ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Binary tiling scheme
Hi, I have created a tiling scheme which is based on division in two parts of a parent cell, alternating in the x and y directions. It can be used to chop up a rectangular area, so that each resulting tile contains less data than a certain threshold. I've devised it as a possible answer to the problem that some of Computerteddy's IMG files, particular in the Netherlands, can't be generated due to their size. This binary scheme is in contrast to the quad tiling scheme which is often used (like in Google Maps, or the CanVec import tiles), where each division ends up in four cells. However, when a quad scheme is used, you'll end up with more redundant tiles, of which the combination does not exceed the threshold either. Another benefit of this binary division is that each subtile can be identified by a unique integer value. This can be very convenient. It also means that the location of the subtile within the base tile, as well as its size, are implicitly stored. This scheme is also not limited by scale. When a parent tile has number n, its children will have the numbers 2*n and 2*n+1. If you're familiar with genealogy, this is the same as the Ahnentafel numbering (Sosa-Stradonitz). However, where as in genealogy a child has two parents, this is completely the opposite here. (A parent tile can be divided into two child tiles.) More information can be found on the OSM wiki: [1]. If you think it is useful, please let me know. Regards, Frank [1] http://wiki.openstreetmap.org/wiki/Binary_tiling_scheme ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Polygon buffer tool (for Osmosis)
Hi, I've created a small Python tool which buffers the polygon in a polygon file (for Osmosis), and creates a new polygon file. It can be found here: [1]. For the buffering PostGIS is used. All Canadian polygon files from [2] have been tested and are working. Requirements: Python (2.6, but 2.5 likely works too), PostGIS (1.3+), PyGreSQL More info can be found in the file itself, or by typing ./polybuffer.py -h in the command prompt. Please let me know any issues you experience with this tool. Cheers, Frank [1] http://svn.openstreetmap.org/applications/utils/osm-extract/polygons/polybuffer.py [2] http://www.maproom.psu.edu/dcw/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
