Re: [OSM-dev] Python XML Parser on Windows

2019-08-07 Thread Frank Steggink

Hi Spencer,

I'd definitely recommend lxml: One of the benefits of 
lxml is that it is cross platform.
You can find Windows binaries for lxml and many other Python libraries 



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.

Thanks for any help

dev mailing list

dev mailing list

Re: [OSM-dev] API 0.7+: Split node concept?

2010-10-12 Thread Frank Steggink

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 :)


dev mailing list

[OSM-dev] Binary tiling scheme

2010-08-29 Thread Frank Steggink


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.




dev mailing list

[OSM-dev] Polygon buffer tool (for Osmosis)

2009-12-10 Thread Frank Steggink

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+), 
More info can be found in the file itself, or by typing ./ 
-h in the command prompt.

Please let me know any issues you experience with this tool.




dev mailing list