Hello,
thanks again for all the links and pointers (openstreetmap wiki pages,
skyhook, openbmap)...
Hello again !
I'm cc-ing for info : Richard Atterer (one of your articles is linked
below), Lulu-Ann (your project and name mentionned), Andy Allan (1 question
for you at the email's bottom).
Hallo Jonathan-David!
My comments in line:
Original-Nachricht
Datum: Wed, 16 Dec 2009 10:50:01 +0100
Von: Jonathan-David SCHRODER jonathan.schro...@gmail.com
An: Emilie Laffray emilie.laff...@gmail.com
CC: John Smith deltafoxtrot...@gmail.com, OpenStreetMap Developers
Hi,
Have you been considering how to handle the history of old anonymous edits?
This new history data should not reveal those user names but keep them
anonymous.
-Jukka Rahkonen-
___
dev mailing list
dev@openstreetmap.org
Have you been considering how to handle the history of old anonymous edits?
This new history data should not reveal those user names but keep them
anonymous.
User IDs and Usernames for those anonymous edits are left out of the
dump. So the elements may not have an uid or user attribute.
Hi Guys,
Wondered if there had been any update on these numbers from the latest planet?
--
Nick
On Sat, Dec 5, 2009 at 9:42 AM, andrzej zaborowski balr...@gmail.com wrote:
Hi,
2009/12/5 Nick Black nickbla...@gmail.com:
Interesting data Matt. Getting more users through the one month zone
On Wed, Dec 16, 2009 at 11:25 AM, Nick Black nickbla...@gmail.com wrote:
Wondered if there had been any update on these numbers from the latest planet?
these are the numbers from today's planet:
editor | num | num_data | num_users
Hi,
For several reasons I am not permanently up to date with osm.
Revently I noticed that (obviously due to changes from api) the
timestamp is handled differently and set to the upload date-time after
creating a node/relation/way.
Personnally I think this is strange, but could anyone direct me to
On 16/12/09 16:24, hy-soft wrote:
For several reasons I am not permanently up to date with osm.
Revently I noticed that (obviously due to changes from api) the
timestamp is handled differently and set to the upload date-time after
creating a node/relation/way.
As opposed to what? A timestamp
hy-soft schrieb:
Revently I noticed that (obviously due to changes from api) the
timestamp is handled differently
Which timestams exactly are you talking about. In the changeset? On the
node? On the Homepage? In the planet.osm? In an api / xapi / trapi response?
Peter
On 16/12/09 17:02, hy-soft wrote:
Tom Hughes wrote:
As opposed to what? A timestamp specified in the uploaded XML file?
That has (as far as I know) always been the case - any timestamp in the
uploaded XML is discarded. Certainly I believe API's 0.4 to 0.6 have
worked in that way, which
Peter Körner wrote:
hy-soft schrieb:
Revently I noticed that (obviously due to changes from api) the
timestamp is handled differently
Which timestams exactly are you talking about. In the changeset? On the
node? On the Homepage? In the planet.osm? In an api / xapi / trapi
response?
Tom Hughes wrote:
On 16/12/09 16:24, hy-soft wrote:
For several reasons I am not permanently up to date with osm.
Revently I noticed that (obviously due to changes from api) the
timestamp is handled differently and set to the upload date-time after
creating a node/relation/way.
As
for JOSM:
lang | num | num_users
---++---
de| 491078 | 6457
en| 240905 | 3086
| 76081 | 2704
fr| 91720 | 919
en_GB | 55408 | 852
ru| 45467 | 527
it| 34936 | 357
es| 21888 | 248
nl
Hey guys,
I really need some help, I been trying to debug this problem for days but still
no luck,
I am sure there are people on this forum who have the knowledge to help out.
My setup: Window xp, P4, 3.0Gigs, 4 gigs of ram. Only 12 gigs of hard drive
space available
- Is hard drive space a
Note: Other OSM data such as, california.osm or asia.osm works,
osm2pgsql is able to
read the data... I believe the planet.osm is corrupted while
unzipping/downloading?
I beleive your osm2pgsql is outdated. california.osm co. does not
contain changeset ..-elements while the planet.osm
Drive space is a likely problem - the planet may require an additional 60-70 GB
to populate the Postgres DB. You may be able to make it work by first
compressing the planet as a .bz2 file; that will free up about 110 GB of space.
osm2pgsql can read from this compressed file.
From: Quy
Hmm interesting, thank you for your response,
any way I can get the most-up-to-date osm2pgsql?
I been trying to search the internet to find it... No luck.
The windows binary version would be great.
Looking for the udpated osm2pgsql
Date: Wed, 16 Dec 2009 20:36:55 +0100
From:
On Wed, Dec 16, 2009 at 18:58, Matt Amos zerebub...@gmail.com wrote:
Thanks for those language stats, they were very informative.
not sure what the null language results are - presumably at some point
the editors weren't putting a language in their changeset comments or
something?
No, I only
On Wed, 2009-12-16 at 11:46 -0800, Quy phan wrote:
Hmm interesting, thank you for your response,
any way I can get the most-up-to-date osm2pgsql?
I been trying to search the internet to find it... No luck.
The windows binary version would be great.
Looking for the udpated osm2pgsql
As per
Hi there bernhard - including a , with the lang=de parameter was a
bug. Its now been corrected and all languages return a . as the
decimal separator.
--
Nick
n...@cloudmade.com
On Thu, Dec 3, 2009 at 10:08 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
bernhard wrote:
Localization extrem:
Hello,
thanks for CCing me, Jonathan-David! It's great to see other people are
interested in indoor navigation! I just subscribed to the dev list.
On Wed, Dec 16, 2009 at 10:50:01AM +0100, Jonathan-David SCHRODER wrote:
Outside of openstreetmap's site, we have found several people mentioning
On 16/12/09 21:34, hy-soft wrote:
Tom Hughes wrote:
That's certainly never been the case because no editor has ever provided
the ability to set a date for an object in that way. The most they could
ever have done is to set the date it was entered into the editor.
But, like I say, I don't
Tom Hughes wrote:
On 16/12/09 17:02, hy-soft wrote:
Tom Hughes wrote:
That's certainly never been the case because no editor has ever provided
the ability to set a date for an object in that way. The most they could
ever have done is to set the date it was entered into the editor.
I think
Tom Hughes wrote:
On 16/12/09 21:34, hy-soft wrote:
Tom Hughes wrote:
When I do an upload of a node via the api, every other tag looks fine,
but the datetime is set to the time of upload.
Which is exactly what I said, and exactly what it has always done. That
is what I said earlier and
Hi,
hy-soft wrote:
GPS-tracks usually have a timestamp. So, I thought, when importing data,
this timestamp is preserved. Every Editor should preserve it and not
touch it (unless $user chooses to tamper with it).
That's exactly what we do with GPS tracks; if you upload them, the
timestamp is
Hello Dave,
I've created the only abstract class with the logic of tag transforming
already committed, after running some tests.
Best regards,
Popov Anton
On Mon, Dec 7, 2009 at 8:10 PM, Dave Stubbs osm.l...@randomjunk.co.ukwrote:
Hi,
Good to see someone working on improvements!
I just
Kirill Bestoujev wrote:
Hi!
How do you think a shell script will work in Windows???
Well, the windows world has their proprietary BAT files, so a shell
script could be ported. Would be nice if Microsoft would join us in the
third millennium and drop their VMS-based OS offerings in favor of
2009/12/8 Matthias Julius li...@julius-net.net
Yes, I understand that, but a user tracing imagery will probably be
expecting the application to behave like a drawing application, with
an 'extrude' operation extruding perpendicular to the object as seen
on screen, not going off in some
28 matches
Mail list logo
