[OSM-dev] josm translations?

Hi,

I couldn't find the sources for the josm translations. I'd like to do some 
fixes for the german translations.

--

-- 
Hanno Böck		Blog:   http://www.hboeck.de/
GPG: 3DBD3B20		Jabber: hanno <at> hboeck.de

_______________________________________________
dev mailing list
dev <at> openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev

Re: [OSM-dev] josm translations?

Hi,

> I couldn't find the sources for the josm translations. I'd like to do some 
> fixes for the german translations.

No idea about the source either but Sven Anders (Cc) might know.

Bye
Frederik

--

-- 
Frederik Ramm  ##  eMail frederik <at> remote.org  ##  N49°00.09' E008°23.33'

Re: [OSM-dev] josm translations?

Hanno Böck schrieb:
> Hi,
>
> I couldn't find the sources for the josm translations. I'd like to do some 
> fixes for the german translations.
>
>   
I guess, the translation is in the svn at 
svn.openstreetmap.org\applications\editors\josm\plugins\lang\de

But please don't ask me how this works, I didn't worked with it before.

Regards, ULFL

Re: [OSM-dev] OSM Date Formats

This probably should go to Frederik but I'll post it here anyway in case 
others are interested or have issues/comments.

I've attached a patch to JOSM modifying its date handling.  This patch 
copies in most of the osmosis date handling code which I think is an 
improvement on the existing JOSM date handling code.

Firstly it modifies JOSM to write dates in UTC XML format.  I would have 
used XmlGregorianCalendar but it includes millisecond information and I 
can't find a way to remove it.  I've written a custom formatter 
instead.  It has a bug when writing dates before baby Jesus was visited 
by the wise men (ie. BC dates require a negative year in XML) but I 
haven't found any data that old in the OSM database so I didn't bother 
fixing it.

The existing date writer just wrote a date without timezone information 
so JOSM was always applying local timezone to dates.  This is okay for 
normal editing but not good if you load files written in another timezone.

It also fixes the date parser.  The existing parser wasn't making use of 
XmlGregorianCalendar which takes care of all xml date formats.  I've 
updated it to first try my custom parser used in osmosis and if that 
doesn't recognise the format to fallback to XmlGregorianCalendar and 
finally to fall back to the old JOSM parser (a slightly modified version 
of it).  Given that parse performance isn't an issue for JOSM sized 
files, the custom bit could probably be deleted but note that the 
XmlGregorianCalendar performance is atrocious on UTC dates (not so bad 
for dates with an offset) for reasons which I won't go into here.

The existing parser can't parse 2007-01-12T13:46:40Z properly, it loses 

[OSM-dev] Importing planet.osm into api0.5 db?

Hi,

I setup a test server to play around with, and I figured I'd use the
0.5 api version, since it's going to go live soon anyway.  I
downloaded the 0.5 planet.osm linked from the wiki, but now I can't
figure out how to import it to the database.  There are a lot of tools
in applications/utils/planet.osm, but I'm not sure which (if any) have
been updated to support 0.5.  I tried Osmosis, but it complains "The
database schema version of 8 does not match the expected version of
6".  Presumably this is due to the quadtiles update that was mentioned
previously.  Is there another tool I can use to accomplish this?

Thanks,
-Ted

Re: [OSM-dev] Importing planet.osm into api0.5 db?

Hi,

> I downloaded the 0.5 planet.osm linked from the wiki, but now I
> can't figure out how to import it to the database.

I must admit that I never did this myself 

Osmosis should do it and it would be great if you could test it, the
schema error message is surely just a minor glitch.

But you can also download the 1.7 GB file at

http://openstreetmap.gryph.de/planet-api05-070927.sql.bz2

which is a full mysql dump of a working installation.

Bye
Frederik

--

-- 
Frederik Ramm  ##  eMail frederik <at> remote.org  ##  N49°00.09' E008°23.33'

[OSM-dev] Planet.xml in MonetDB (39GB...)

Hi,

Yesterday I managed to import the 'old' API, 28-09-2007, into the
MonetDB4 XML database server. After 39GB of storage data, I found out it
is in a working state.

For my courses on SQL vs XQuery I am investigating the performance of
both. I guess it is pretty unique someone actually imported the Planet
XML before converting it, and if one like to shoot some XQuery work on
it I'm happy to run it.

My idea was the following:
Investigate if OSM can run from a XML database only
Provide the API via XQuery
Make instant graphical updates upon data-updates.

Next to this, I would like to tryout XaraLX as renderer, instead of
Inkscape.

Stefan

Re: [OSM-dev] Importing planet.osm into api0.5 db?

On 10/1/07, Frederik Ramm <frederik <at> remote.org> wrote:
> I must admit that I never did this myself 
>
> Osmosis should do it and it would be great if you could test it, the
> schema error message is surely just a minor glitch.

If I pass "validateSchemaVersion=no" to osmosis, it fails with an exception:

Exception in thread "Thread-1-read-xml-0.5"
com.bretth.osmosis.core.OsmosisRuntimeException: Unable to set a
prepared statement parameter for a node.
        at com.bretth.osmosis.core.mysql.v0_5.MysqlWriter.populateNodeParameters
(MysqlWriter.java:384)

I guess this doesn't work.  :)

Regards,
-Ted

Re: [OSM-dev] extract_polygon_0.5.pl bugs

Hi,

> I did my counting backwards hack mostly to avoid allocating another
> 250MB of RAM with another set of Bit::Vector objects, *and* to allow
> positive and negative integers.  
> 
> Still haven't gotten to cleaning up the patch to a bare minimum.
> Hopefully I'll get to it tonight.

The 0.4 polygon extract tool used Perl hashes for everything and it
worked ok if the areas were not too big. 

May I suggest to keep the existing Bit::Vector strategy for positive
IDs and recurse to the old hashtable strategy for negative numbers,
assuming that there will not be too many of them.

The counting backwards thing is probably ok as well but I suspect it
requires a hefty amount of checks and balances in order not to break
things...

Bye
Frederik

--

-- 
Frederik Ramm  ##  eMail frederik <at> remote.org  ##  N49°00.09' E008°23.33'

[OSM-dev] status of osmarender 5 and api 0.5

What is the status of api 0.5 support in Osmarender 5?  On the wiki
(http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5#Development_status)
there is a note that there is alpha support, but nothing appears to be
in svn.  Is there a branch I should be checking out?

Thanks,
James