Hi everyone,
I'd like to build weekly planet.osm files for the September 2007 using
planetpatch utility (
http://svn.openstreetmap.org/applications/utils/planetdiff/).
I'm running the following command:
./planetpatch planet-070905.osm.bz2 planet-070905-070912.diff.xml.bz2
planet-070912.osm
But
On Tue, Sep 2, 2008 at 2:47 PM, Mitya Korochkin [EMAIL PROTECTED] wrote:
Hi everyone,
I'd like to build weekly planet.osm files for the September 2007 using
planetpatch utility
(http://svn.openstreetmap.org/applications/utils/planetdiff/).
I'm running the following command:
./planetpatch
Hi,
Dave Stubbs wrote:
Yes, these planets are from before the 0.5 API switch over (which
happened on 6th/7th October 2007). I think you'll need to process them
with a 0.4 version of the planetdiff tool (ie: r4778 in SVN). Any
tools you use will need to know about segments, or else you'll need
This needs some amendments from the other devs, because I can only speak
for the changes I made or participated in.
* New fallback API
* New fallback logic in case the client gets no data
* make oceantiles stuff an external, so it's easier to keep in sync with
multiple client branches.
*
Thanks many times for pinpointing the problem!
The recent build of josm is actually pretty descriptive about which
nodes/ways/relations have a problem during
uploads. You have to make sure you can see this output tough... Maybe not
only add the errors on the commandline,
but make sure the
Hello,
so the plugin is in josm like ewmsplugin. You can test the plugin easily
now.
On Mon, 01 Sep 2008 22:20:44 +0200, Petr Dlouhý [EMAIL PROTECTED]
wrote:
I would like to commit my changes, so my plan is following:
1) I will commit the changes to wmsplugin SVN.
2) I will commit the
On Mon, Sep 1, 2008 at 8:06 PM, Henry Loenwind [EMAIL PROTECTED] wrote:
(1) there is a bug tracker
I know, but I wasn't sure that this was a JOSM issue as mentioned in my posting.
(2) not a bug. The server delivers all GPS points in the downloaded area as
one tracks---that gives the jumps
Hello,
now that I found a charset conflict in measurement plugin: Is there any
definition in which charset the jar files are?
Could we agree to use UTF-8 here or only plain ASCII?
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
___
josm-dev
Dirk Stöcker schrieb:
Hello,
now that I found a charset conflict in measurement plugin: Is there any
definition in which charset the jar files are?
Could we agree to use UTF-8 here or only plain ASCII?
Ciao
I would strongly recommend UTF-8
On 02/09/2008 18:19, Henrik Niehaus wrote:
To make this process easier, I wrote a plugin, which downloads the data
of the current visible bounding box. You can scroll to the desired place
and then start the plugin.
But isn't that what happens anyway if you just press OK without putting
Hi,
Dirk Stöcker wrote:
now that I found a charset conflict in measurement plugin: Is there any
definition in which charset the jar files are?
You mean the java source code files? I don't see why they should be
anything else than good old 7-byte ASCII. We don't want any national
language
Hi,
To make this process easier, I wrote a plugin, which downloads the data
of the current visible bounding box. You can scroll to the desired place
and then start the plugin.
But isn't that what happens anyway if you just press OK without putting
anything in the dialog box?
I was
Henrik Niehaus wrote:
D'oh,
you are both right. I didn't notice that the values in the download
dialog are adjusted, though it's mentioned in the help, too. I think a
hint in the download dialog, that the values are automatically adjusted,
would be helpful.
Good, that I had to write only a
13 matches
Mail list logo