Thanks for investigating this, Jochen! Just a small correction: when you wrote
> There was a problem with hourly and daily diffs missing some changes on Nov
> 11 2020.
I assume actually meant November 29, right?
___
dev mailing list
I believe the formula just implements the interleaving of the X and Y
coordinates used in the QuadTiles[1] indexing schema in an efficient
way by using some clever bit operations.
[1] https://wiki.openstreetmap.org/wiki/QuadTiles#Quadtile_implementation
On Tue, Jan 14, 2020 at 11:11 AM Lorenzo
Hi,
you may want to take a look at iD's source code. Depending on what you
actually need, some of its code might be reusable (in form of
ES6-modules). For example, the code handling the interaction with
OSM's editing API is found here:
It works for me (using tiny-osmpbf [0]): I see 2228689 "visible" and
160919 deleted node versions. Maybe osm4j doesn't read the visible
flag from the DenseInfo[1] data structure in the pbf file?
Best,
Martin
[0] https://www.npmjs.com/package/tiny-osmpbf
[1]
26, 2016 at 11:41 AM, Tom Hughes <t...@compton.nu> wrote:
> On 26/08/16 08:56, Martin Raifer wrote:
>
>> As you can clearly see, the dates mentioned in the logs' file names
>> don't match up with the actual event.
>>
>> Could it be that the dates are of
Hi,
I'm looking at the OSM tile log files [1] as provided on
planet.osm.org. I can't find any documentation for it on the osm wiki.
While most of it is quite self-explanatory, I'm wondering what the
dates in the filenames actually mean. For example, if one looks at
`tiles-2016-08-23.txt.xz` does
> Martin mentioned a deviation of exactly 4 seconds
Well, actually, the 4 seconds were only for the one example changeset.
In other changesets, I saw different time differences (most were even
smaller if I recall it correctly).
___
dev mailing list
I noticed that the timestamps in the changeset metadata doesn't
exactly match the timestamps of their created, modified or deleted
data in some recent changesets. In the affected changesets, the
timestamps of the data objects are a couple of seconds earlier than
the reported changeset-opening
Hey Jochen,
Very nice. Even though I've only skimmed over your blog post jsut now,
this already reminds me very much of what the Overpass API has been
doing for a while now in the full-geometry output mode (see for
example http://overpass-turbo.eu/s/fMI), which btw. even works for
relations (and
A reasonable ballpark value could be the date when the pull request to
add the respective project file was opened on github:
https://github.com/taginfo/taginfo-projects/pulls?q=is%3Apr+is%3Aclosed
Martin
On Tue, Feb 16, 2016 at 2:11 PM, Philipp Hukal
wrote:
> Hi!
There are several ways to accomplish a kind of separation between the
"matched" content and the "referenced" (geometry containing) objects.
The most basic one would be to simply divide the query into two: First
only outputting the matched content, and second outputting referenced
objects. This has
Dear Divyanshu,
We have recieved your proposal. Thank you very much!
I'll go through it in detail as soon as possible and if there was
anything to change, I'd let you now.
Best regards,
Martin
On Tue, Mar 24, 2015 at 5:02 AM, Divyanshu Maithani
div.black...@gmail.com wrote:
Greetings OSM
Dear Nikhil,
Learning platform for Overpass API
The primary goal of this project is to make it easier for newcomers to
learn and use the Overpass API for querying OSM data. This includes
well structured documentation, guidelines, tutorials, learning
courses, etc. But that doesn't necessarily
Yes. Just replace the first print statement (`print mode=body/`)
with `print mode=body geometry=center/` and drop the following
two lines (recurse and second print). This will give you the
coordinates for all nodes and an approximate* centroid for all ways
and relations in the result set. Example:
There already exists the project doesitrender by Stefano Sebastiani
that tries to extract the tags that are used for rendering the
openstreetmap-carto style: https://github.com/sabas/doesitrender
Martin
___
dev mailing list
dev@openstreetmap.org
I am not sure yet what exactly the valid and invalid mean and
whether we need different outcomes. For the moment valid means more
something like: The data looks good, could exist in a real database,
and everybody would agree on how to interpret it. While invalid is
everything else.
I suppose
Hey!
I think this could be of use for someone: osmtogeojson, as the name
suggests, is an OSM-to-GeoJSON converter. It's written as a javascript
library, but can also be used as a command line tool: After installing it
via `npm install -g osmtogeojson` you can use it like this:
(is there a json checker tool that looks for missing braces?)
Yes, jsonlint: https://npmjs.org/package/jsonlint#readme
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
amrit karmacharya amrit...@gmail.com wrote:
I have uploaded data on dev server
[...]
Is there a easy way like overpass to get data from the dev server?
As far as I know, there is no planet file (and neither there are diffs)
for the dev server. Thus, it is impossible to create an Overpass
Hi!
Just a wild guess (didn't try), but what if you rendered your map in an
equal area projection (e.g. Mollweide) and reprojected the resulting
raster image - in a second step - to equirectangular (for example using
GDAL)? That could result in something more towards your objective...
Can someone point me to an XAPI server with fairly fresh data?
Just use the XAPI compability layer[1] provided by Overpass API:
http://www.overpass-api.de/api/xapi?...
[1]
http://wiki.openstreetmap.org/wiki/Overpass_API/XAPI_Compatibility_Layer
Martin
get a JSON Array with location data in types and nearby a location
Sounds like a use-case for Overpass API [1].
Take a look at the following example: http://overpass-turbo.eu/s/dD
Martin / tyr_asd
[1] http://wiki.openstreetmap.org/wiki/Overpass_API
I think this might be a little bit too technical for the talk-ML, so I'm
posing this here:
22.03.2013, 23:38, Roland Olbricht roland.olbri...@gmx.de wrote:
And there is even a future driven reason to encourage feedback: In the
long term, Overpass API will produce GeoJSON to allow vector
Hello Stefan
I mentioned client side generation of GeoJSON from OSM data as an
alternative to a central GeoJSON API approach (which API is not
available yet; see below).
As always, it depends on the actual use case. When your application has
its own geo database already, it's probably
Hi
Not really an answer to your question, but anyway:
For overpass turbo [1] I have implemented a converter on client side (as a
Leaflet-Plugin [2]). It supports multipolygons and has some
polygon-detection-magic. As far as I can tell, this client side conversion
is not really a
25 matches
Mail list logo