[OSM-dev] [ANNOUCEMENT] MapOSMatic: automatic generation of cities' map from OpenStreetMap data
== Short Version == We are pleased to announce the release of MapOSMatic, a set of tools to automatically generate cities' map from OpenStreetMap data. MapOSMatic takes care of generating a labelled grid over the map, a list of street with references matching the grid as well as a nice layout of the city if its administrative boundaries are known. For now, it only supports rendering French metropolitan cities' maps, but it will soon be extended to other parts of the world. MapOSMatic is Open Source / Free Software licensed under AGPLv3. Generation of maps can be requested on-line: http://maposmatic.org/ Example of generated map: * Map: http://maposmatic.org/smedia/chavagne.png http://maposmatic.org/smedia/chavagne.pdf * Street index: http://maposmatic.org/smedia/chavagne_index.png http://maposmatic.org/smedia/chavagne_index.pdf == Longer Version == = MapOSMatic = MapOSMatic is a web application to generate maps of cities or towns, including index of streets, from OpenStreetMap data. It is written in Python. http://maposmatic.org/ It is made of two components: * MapOSMatic, the web front-end. An application written using the Django framework which allows to submit and visualize map rendering jobs. The rendering is done in the background by a daemon called maposmaticd; * OCitySMap, the back-end that generates the map. It is available as a Python module, used both by the maposmaticd daemon (above) and by a simple command line application. MapOSMatic is currently limited to France metropolitan area for several technical reasons. We are eager to get contribution helping us to lift up this limitation. MapOSMatic depends on PostgreSQL, PostGIS, Mapnik, OpenStreetMap data, Python, Cairo and Django. = License = MapOSMatic is Open Source / Free Software. All maposmatic and ocitysmap code is licensed under GNU Affero General Public License 3.0. = Contributing = The MapOSMatic development project is hosted at Savannah: http://savannah.nongnu.org/projects/maposmatic/ A development and user mailing list is available: http://lists.nongnu.org/mailman/listinfo/maposmatic-dev To clone the git repositories of modules do: git clone git://git.savannah.nongnu.org/maposmatic.git git clone git://git.savannah.nongnu.org/maposmatic/ocitysmap.git To browse those git repositories, look at: * http://git.savannah.gnu.org/cgit/maposmatic.git * http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git Yours, david -- for maposmatic.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSMOSIS-Dataconverting APi0.5 - Api0.6 problem
Hello, one year ago I've set up an OSM-Server with API 0.5. Now we've switched to a new Debian-Server with API 0.6 and postgres-DB. To import the old data from the old API-05-Server into the new API06-Server I've tried the steps below-mentioned. During the import osmosis is terminating with the following error: Unable to bulk insert node tags into the database. ... Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(255) ... 1) Data export on the old Server (Api 0.5. mysql-DB, osmosis 0.29): osmosis --read-mysql database=openstreetmap user=openstreetmap password=xyz validateSchemaVersion=no --wx Data_API05.osm.bz2 2) Dataimport on the new Debian-Server (Api 0.6 postgres-DB, osmosis 0.31.2): a) osmosis --read-xml-0.5 Data_API05.osm.bz2 --migrate --write-xml-0.6 Data_API06.osm.bz2 b) osmosis --read-xml-0.6 file=Data_API06.osm.bz2 --write-apidb-0.6 populateCurrentTables=yes host=localhost database=openstreetmap user=openstreetmap password=xyz validateSchemaVersion=no It's possible to import a complete planet-file without any errors - hmmm. I've spent two days to find a solution and tried a lot of data converting. Not sure what I'm doing wrong. Has anybody an idea? Thanks !!! Sabine --- osmosis -v --read-xml-0.6 file=InputFile_API06.osm.bz2 --write-apidb-0.6 populateCurrentTables=yes host=localhost database=openstreetmap user=openstreetmap password=xyz validateSchemaVersion=no Sep 10, 2009 9:49:58 AM org.openstreetmap.osmosis.core.Osmosis run INFO: Osmosis Version 0.31.2 Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.TaskRegistrar loadJPFPlugins FINE: Searching for JPF plugins. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.TaskRegistrar loadJPFPlugins FINE: Registering the core plugin. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.TaskRegistrar loadJPFPlugins FINE: Registering the extension plugins. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.Osmosis run INFO: Preparing pipeline. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.Pipeline prepare FINE: Building tasks. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.Pipeline buildTasks FINE: Created task 1-read-xml-0.6 Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.Pipeline buildTasks FINE: Created task 2-write-apidb-0.6 Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.Pipeline prepare FINE: Connecting tasks. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.PipeTasks putTask FINE: Task 1-read-xml-0.6 produced unnamed pipe stored at level 1 in the default pipe stack. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.Pipeline connectTasks FINE: Connected task 1-read-xml-0.6 Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.PipeTasks retrieveTask FINE: Task 2-write-apidb-0.6 consumed unnamed pipe stored at level 1 in the default pipe stack. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.Pipeline connectTasks FINE: Connected task 2-write-apidb-0.6 Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.Osmosis run INFO: Launching pipeline execution. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager execute FINE: Launching task 1-read-xml-0.6 in a new thread. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.PassiveTaskManager execute FINE: Task 2-write-apidb-0.6 is passive, no execution required. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.Osmosis run INFO: Pipeline executing, waiting for completion. Sep 10, 2009 9:49:59 AM org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager waitForCompletion FINE: Waiting for task 1-read-xml-0.6 to complete. Sep 10, 2009 9:52:01 AM org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager waitForCompletion SEVERE: Thread for task 1-read-xml-0.6 failed org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to bulk insert node tags into the database. at org.openstreetmap.osmosis.core.apidb.v0_6.ApidbWriter.flushNodeTags(ApidbWriter.java:617) at org.openstreetmap.osmosis.core.apidb.v0_6.ApidbWriter.addNodeTags(ApidbWriter.java:1092) at org.openstreetmap.osmosis.core.apidb.v0_6.ApidbWriter.flushNodes(ApidbWriter.java:573) at org.openstreetmap.osmosis.core.apidb.v0_6.ApidbWriter.process(ApidbWriter.java:1078) at org.openstreetmap.osmosis.core.container.v0_6.NodeContainer.process(NodeContainer.java:58) at org.openstreetmap.osmosis.core.apidb.v0_6.ApidbWriter.process(ApidbWriter.java:1052) at org.openstreetmap.osmosis.core.xml.v0_6.impl.NodeElementProcessor.end(NodeElementProcessor.java:109) at org.openstreetmap.osmosis.core.xml.v0_6.impl.OsmHandler.endElement(OsmHandler.java:108) at
Re: [OSM-dev] [ANNOUCEMENT] MapOSMatic: automatic generation of cities' map from OpenStreetMap data
On Thu, Sep 10, 2009 at 10:14, David MENTRE dmen...@linux-france.org wrote: We are pleased to announce the release of MapOSMatic, a set of tools to automatically generate cities' map from OpenStreetMap data. MapOSMatic takes care of generating a labelled grid over the map, a list of street with references matching the grid as well as a nice layout of the city if its administrative boundaries are known. For now, it only supports rendering French metropolitan cities' maps, but it will soon be extended to other parts of the world. MapOSMatic is Open Source / Free Software licensed under AGPLv3 WHOA! This is something I've been hoping for a long time... Thanks...I'm sure you will soon find many people ready to contribute translations. Is the limitation to france just because of postgis size? or is it something different? -- -S ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [ANNOUCEMENT] MapOSMatic: automatic generation of cities' map from OpenStreetMap data
Bonjour, Une super application pour montrer au monde à quoi ça sert de saisir des cartes qui sont déjà dans ... Sinon, pour la prochaine version serait possible d'avoir un PDF unique comportant la carte et la liste des rues sur 2 pages successives, histoire de l'imprimer en recto/verso facilement. Merci encore pour votre travail (j'en ai rêvé, vous l'avez fait). -- Marc - David MENTRE dmen...@linux-france.org a écrit : == Short Version == We are pleased to announce the release of MapOSMatic, a set of tools to automatically generate cities' map from OpenStreetMap data. MapOSMatic takes care of generating a labelled grid over the map, a list of street with references matching the grid as well as a nice layout of the city if its administrative boundaries are known. For now, it only supports rendering French metropolitan cities' maps, but it will soon be extended to other parts of the world. MapOSMatic is Open Source / Free Software licensed under AGPLv3. Generation of maps can be requested on-line: http://maposmatic.org/ Example of generated map: * Map: http://maposmatic.org/smedia/chavagne.png http://maposmatic.org/smedia/chavagne.pdf * Street index: http://maposmatic.org/smedia/chavagne_index.png http://maposmatic.org/smedia/chavagne_index.pdf == Longer Version == = MapOSMatic = MapOSMatic is a web application to generate maps of cities or towns, including index of streets, from OpenStreetMap data. It is written in Python. http://maposmatic.org/ It is made of two components: * MapOSMatic, the web front-end. An application written using the Django framework which allows to submit and visualize map rendering jobs. The rendering is done in the background by a daemon called maposmaticd; * OCitySMap, the back-end that generates the map. It is available as a Python module, used both by the maposmaticd daemon (above) and by a simple command line application. MapOSMatic is currently limited to France metropolitan area for several technical reasons. We are eager to get contribution helping us to lift up this limitation. MapOSMatic depends on PostgreSQL, PostGIS, Mapnik, OpenStreetMap data, Python, Cairo and Django. = License = MapOSMatic is Open Source / Free Software. All maposmatic and ocitysmap code is licensed under GNU Affero General Public License 3.0. = Contributing = The MapOSMatic development project is hosted at Savannah: http://savannah.nongnu.org/projects/maposmatic/ A development and user mailing list is available: http://lists.nongnu.org/mailman/listinfo/maposmatic-dev To clone the git repositories of modules do: git clone git://git.savannah.nongnu.org/maposmatic.git git clone git://git.savannah.nongnu.org/maposmatic/ocitysmap.git To browse those git repositories, look at: * http://git.savannah.gnu.org/cgit/maposmatic.git * http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git Yours, david -- for maposmatic.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [ANNOUCEMENT] MapOSMatic: automatic generation of cities' map from OpenStreetMap data
Hello, 2009/9/10 Simone Cortesi sim...@cortesi.com: Is the limitation to france just because of postgis size? or is it something different? We have three main limitations: * locale used for sorting is hard coded to fr_FR currently: http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/street_index.py#n472 * Street prefixes are hard-coded for French: http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/street_index.py#n35 * We have only made an import of france.osm.bz2 (could be easily solved, modulo the size of our web server). Of course, we also need a way to control that through the web interface. Yours, d. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [ANNOUCEMENT] MapOSMatic: automatic generation of cities' map from OpenStreetMap data
2009/9/10 David MENTRE: limitations: * Street prefixes are hard-coded for French: http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/street_index.py#n35 as you may know there is a list of prefixes in the wiki http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations and this other list of translations, should you decide to provide thematic maps ;-) http://wiki.openstreetmap.org/wiki/Name_finder:Translations if you need to translate something into Italian, just ask -- Daniele Forsi ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keeping .osm database up-to-date
Sorry for being a noob, but what is the perpose of threading it though osmosis using -rci. Why not run a cron that does ./osm2pgsql -a ../diff.ocm? 2009/9/9 Frederik Ramm frede...@remote.org Hi, Richard Ive wrote: When you say read the diffs. Do you mean download the weekly planet from osm.org http://osm.org, and then run it though osmosis. Would you be happy sending me an example of your set-up? There is a detailed example at http://wiki.openstreetmap.org/wiki/Minutely_Mapnik This uses minuetly diffs but you can do the same with hourly. Bye Frederik -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSMOSIS-Dataconverting APi0.5 - Api0.6 problem
Sabine, sabine.te...@gmx.de wrote: Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(255) This is probably just what it says - you seem to have a node with a tag value of more than 255 characters. That was ok with 0.5 but is not ok any more. I suggest that you check your Data_API06.osm.bz2 file (simply running it through something like bzcat Data_API06.osm.bz2 | perl -ne 'print line $. too long\n if (length($_)250);' and then manually shorten the tags in question before proceeding. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keeping .osm database up-to-date
Richard Ive wrote: Sorry for being a noob, but what is the perpose of threading it though osmosis using -rci. Why not run a cron that does ./osm2pgsql -a ../diff.ocm? Osmosis --rci takes care of downloading and merging of diffs for you. Say your cron doesn't run for a while, for whatever reason. Osmosis remembers the last diff it downloaded, and will pick up where it stopped, merge all more recent diffs that it finds, and pipes that to osm2pgsql in one stream. Say your diff import takes more than the time between your cron runs, and again, it's very handy that osmosis takes care of a lot of diff bookkeeping for you. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keeping .osm database up-to-date
Oh wow. That sounds very useful. Is http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--read-change-interval_.28--rci.29the only documentation available for this? 2009/9/10 Lennard l...@xs4all.nl Richard Ive wrote: Sorry for being a noob, but what is the perpose of threading it though osmosis using -rci. Why not run a cron that does ./osm2pgsql -a ../diff.ocm? Osmosis --rci takes care of downloading and merging of diffs for you. Say your cron doesn't run for a while, for whatever reason. Osmosis remembers the last diff it downloaded, and will pick up where it stopped, merge all more recent diffs that it finds, and pipes that to osm2pgsql in one stream. Say your diff import takes more than the time between your cron runs, and again, it's very handy that osmosis takes care of a lot of diff bookkeeping for you. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keeping .osm database up-to-date
Richard Ive wrote: Is http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--read-change-interval_.28--rci.29 the only documentation available for this? The example on the Minutely Mapnik wiki page is useful too, but yeah, your link points to the official osmosis documentation. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Keeping .osm database up-to-date
Don't worry actually. That's more than enough documentation :P 2009/9/10 Richard Ive rich...@xanox.net Oh wow. That sounds very useful. Is http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--read-change-interval_.28--rci.29the only documentation available for this? 2009/9/10 Lennard l...@xs4all.nl Richard Ive wrote: Sorry for being a noob, but what is the perpose of threading it though osmosis using -rci. Why not run a cron that does ./osm2pgsql -a ../diff.ocm? Osmosis --rci takes care of downloading and merging of diffs for you. Say your cron doesn't run for a while, for whatever reason. Osmosis remembers the last diff it downloaded, and will pick up where it stopped, merge all more recent diffs that it finds, and pipes that to osm2pgsql in one stream. Say your diff import takes more than the time between your cron runs, and again, it's very handy that osmosis takes care of a lot of diff bookkeeping for you. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Richard Ive. -- Regards, Richard Ive. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSMOSIS-Dataconverting APi0.5 - Api0.6 problem
Thanks! I've found more then 685 nodes with tag values 255 characters ... nice work to change them ... but now it's working! I've thought, osmosis is creating 0.6-files with all changes. Thanks again for your help! Sabine Original-Nachricht Datum: Thu, 10 Sep 2009 12:06:16 +0200 Von: Frederik Ramm frede...@remote.org An: sabine.te...@gmx.de CC: dev@openstreetmap.org Betreff: Re: [OSM-dev] OSMOSIS-Dataconverting APi0.5 - Api0.6 problem Sabine, sabine.te...@gmx.de wrote: Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(255) This is probably just what it says - you seem to have a node with a tag value of more than 255 characters. That was ok with 0.5 but is not ok any more. I suggest that you check your Data_API06.osm.bz2 file (simply running it through something like bzcat Data_API06.osm.bz2 | perl -ne 'print line $. too long\n if (length($_)250);' and then manually shorten the tags in question before proceeding. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] JAVA-Lib similar OpenLayers
Hello, does anybody know an JAVA-Library with similar features like OpenLayers Javascript-Lib? I would like to enhance our Java-Client to get maps from WMS-Servers. Thanks for your effort. Olli -- Sic! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JAVA-Lib similar OpenLayers
2009/9/10 Oliver Koppisch oli...@koppisch.net: Hello, does anybody know an JAVA-Library with similar features like OpenLayers Javascript-Lib? I would like to enhance our Java-Client to get maps from WMS-Servers. Thanks for your effort. Java for what platform? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
Grant Slater wrote: Politely, hell no. Compare total hardware usage and cost of operating and coordinating ti...@home* layer versus mapnik layer. Mapnik layer still operates from 1 server! hey, so does t...@h. It operates from 1 server. Just uses a few more clients :). * t...@h got us here, but mapnik can carry up further. It would be excellent to see the performance APIs which grew from t...@h growing more useful, maybe towards a feature set like xapi? I would love to see more ROMAs and TRAPIs put in place (fast read only mirror), also XAPIs that allow convenient filtering might be nice) What about the search server. Is that hardware sufficient? Indexing and searching is quite crucial and I seem to recall that the index was only updated every few months due to perf reasons. spaetz signature.asc Description: OpenPGP digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On Wed, Sep 9, 2009 at 7:26 PM, Graham Jones grahamjones...@googlemail.com wrote: I might give this a bit more thought if I get chance - does anyone have a feel for the load on the XAPI servers? - queries per unit time and data rate? There is the munin graphs, but they only give an overview of how much the OSM servers serve. See: http://wiki.openstreetmap.org/wiki/Servers In ancient times there was an anonimized log available that contained lots of data but it has been removed. It would be great to have an updated version of this. http://wiki.openstreetmap.org/wiki/Database#Access_logs And yes having a much faster /api/0.6/map request would be wonderful (I.E. XAPI or ROMA). -- /emj ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [ANNOUCEMENT] MapOSMatic: automatic generation of cities' map from OpenStreetMap data
2009/9/10 David MENTRE dmen...@linux-france.org: 2009/9/10 Simone Cortesi sim...@cortesi.com: Is the limitation to france just because of postgis size? or is it something different? We have three main limitations: * locale used for sorting is hard coded to fr_FR currently: http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/street_index.py#n472 * Street prefixes are hard-coded for French: http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/street_index.py#n35 * We have only made an import of france.osm.bz2 (could be easily solved, modulo the size of our web server). There is a fourth limitation: * function _equal_without_accent() is hard-coded for French: http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/street_index.py#n154 Yours, d. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JAVA-Lib similar OpenLayers
Hi Oliver, does anybody know an JAVA-Library with similar features like OpenLayers Javascript-Lib? I would like to enhance our Java-Client to get maps from WMS-Servers. Thanks for your effort. Depending on what you expect in detail (ready-to-use-library or example code), and whether the licensing of the code is okay for you, you might have a look at the JOSM editor. Although I am not involved in its development, it is written in Java, and from using it I know two components which might be interesting to you: - in the download dialog (Previously you needed a plugin for this, but now, I think, this is included in the program itself), there is a slippy map allowing to choose the area to download (probably just slippy map functionality, not WMS) - In the WMS plugin, there should be code for actually accessing WMS services and underlying it in the view/edit area. Does that help, or do you have other requirements/expectations? Yours, Holger ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JAVA-Lib similar OpenLayers
Hi Holger, ah yes, JOSM. It's obvious. But it's capabilities far exceed our needs. But maybe we can use only the parts we need. I will take a look. Thank you Oliver Am 10. September 2009 21:16 schrieb Holger Schöner nume...@ancalime.de: Hi Oliver, does anybody know an JAVA-Library with similar features like OpenLayers Javascript-Lib? I would like to enhance our Java-Client to get maps from WMS-Servers. Thanks for your effort. Depending on what you expect in detail (ready-to-use-library or example code), and whether the licensing of the code is okay for you, you might have a look at the JOSM editor. Although I am not involved in its development, it is written in Java, and from using it I know two components which might be interesting to you: - in the download dialog (Previously you needed a plugin for this, but now, I think, this is included in the program itself), there is a slippy map allowing to choose the area to download (probably just slippy map functionality, not WMS) - In the WMS plugin, there should be code for actually accessing WMS services and underlying it in the view/edit area. Does that help, or do you have other requirements/expectations? Yours, Holger -- Sic! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
In article 4aa91558.1040...@sspaeth.de sebast...@sspaeth.de writes: I would love to see more ROMAs and TRAPIs put in place (fast read only mirror), also XAPIs that allow convenient filtering might be nice) As far as I can tell, it looks like a single Trapi server could handle all t...@h requests, if it could keep up to date reliably. Unfortunatly, it appears that a single consumer-grade SATA disk is no longer fast enough to keep up with the number of updates beeing done. Combined with the problems generating change files (minute diffs are sometimes delayed, especially when planet file is being generated -- hopefully new dev will solve this) and the change files missing stuff, Trapi hasn't been all that reliable lately. I'm also running into some snags on the new version, that I hoped to have ready months ago. One appears to be a perl bug, and the other is in the fastcgi that only occurs on one of the two systems I've tested on. For a new Trapi server, I think the following is minimal: fast net connection that can handle large volume fast disk: raid0 of 3 or more drives, or enterprise SSD. 100GB is enough. (additional 100GB or more of slow disk is also useful for planet files and logs) 2GB memory. More is better. 2Ghz cpu. Faster/additional cpu has some, but not much, impact. (The first requrement is dropped if you are only running Trapi for a local render farm. I found Trapi used less bandwidth to keep updated than a couple of t...@h renderers.) Note that there isn't any particular reason to colocate with other OSM servers, other than Mat's load-ballancer if that isn't replaced. -- Blars Blarson blar...@scd.debian.net With Microsoft, failure is not an option. It is a standard feature. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Request for help: libosmscout
Hello! I had taken an increasing interest in the data and software side of OpenStreetMap over the last half year, quickly resulting in some hacking on data analysis, map drawing and routing, leading to a C++ library which is already usable (but still far form complete) and is designed to handle all the stuff some navigation software might need for backend. To learn more about it, you can take a look (short video included) at: http://libosmscout.sf.net Note that while this library has a frontend (my initial efforts targeting to the Nokia N810), target is the library that can be used by many backends on multiple platforms. I'm sure not the right person to write a fancy frontend. While I'm sure I will finish it someday in a state fitting my personal needs (I'm satisfied with its progress), a better and quicker result might be interesting for other people, too. Because of that I would like to invite you joining development. If you are interested in helping, do not hesitate to take a look, mail me, subscribe (sourceforge needs some more hours to setup the mailing list) or even hack the code... If in doubt, mail me, too, I do my best to answer all your critical questions :-) I'm looking for clever architects, algorithm junkies, library building experts, OSM data experts, graphical wizards, users, testers etc... I know that documentation is missing, code could be improved, more features are required or existing ones beeing bulky and I'm possibly lacking in-deep OSM knowledge but that should be seen a s a motivation to join and can be fixed quickly if *you* help :-) While you are now beeing overwelmed by this enthusiastic request for help, I must hint that I'm in holiday for a ~10 days starting from the 16.9., so don't be suprised me not answering during this period. -- Gruß... Tim ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] website with problems
Hi, In any case it is OK now and I will not disturb you again. I don't think Dirk didn't feel disturbed per se. But as a developer, you spend a significant amount of time with understanding bug reports. A report always should contain some short description how to reproduce the problem (»If I visit josm.openstreetmap.de and click on blah, I get an 404-error-message. I'm using the opera browser BTW.« or something like this). -- Beste Grüße, Best regards, ce ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
