[osmosis-dev] GRAVE: Execution aborted - Task type repa already exists
Hello, Every time I run osmosis with or without any parameters I get the following text error: 28 mars 2012 08:48:17 org.openstreetmap.osmosis.core.Osmosis run INFO: Osmosis Version 0.39 28 mars 2012 08:48:18 org.openstreetmap.osmosis.core.Osmosis main GRAVE: Execution aborted. org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task type repa already exists. at org.openstreetmap.osmosis.core.pipeline.common.TaskManagerFactoryRegister.register(TaskManagerFactoryRegister.java:44) at org.openstreetmap.osmosis.core.TaskRegistrar.loadPluginClass(TaskRegistrar.java:350) at org.openstreetmap.osmosis.core.TaskRegistrar.loadPlugin(TaskRegistrar.java:306) at org.openstreetmap.osmosis.core.TaskRegistrar.loadBuiltInPlugins(TaskRegistrar.java:123) at org.openstreetmap.osmosis.core.TaskRegistrar.initialize(TaskRegistrar.java:80) at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:81) at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) I run it on Windows 7 64 bit up-to-date, with the latest Java version (64 bit version). I also tried with the latest Java version in 32 bits or on older Java versions, with no success. But osmosis worked on the same computer 6 months ago, so this is very odd. So, what's the problem here? I can't understand the error it generated. Thanks in advance ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
[OSM-dev] Extended diffs
Hello! After some time of thinking what's needed in order to keep osm2pgsql database up-to-date, I've come to idea of extended diffs. In usual OSM diffs, there are only objects that were changed. If a node was dragged, you'll get just that node, and will have to look up that node somewhere in your cache to check if it's in some way, and if that way is in some relation, and for that relation fetch all the member ways, and all the nodes of all the ways. That often leads to broken multipolygons or way geometries (if some nones or ways went off your local database when osmosis/osm2pgsql failed to apply some diff for some reason), and basically happens on every machine in the world that tries to reconstruct geometry from OSM diffs. That stuff also takes time, on slow consumer machines (a.k.a. home servers) it may even take more time to apply a diff than a length of a period for that diff. A minute diff that applies for almost a minute is quite common. To make life easier for such consumers, I think it's worth implementing extended diffs. These can be implemented as a small (osm.pbf? osm.bz2?) file coupled with a diff, that will keep all the stuff that was changed due to applying that diff. Diff itself can be reduced to a small list of things that were deleted. Cons: higher load on OSM servers to select stuff, larger traffic. Pros: all the osm2pgsql databases can be halved in size (slim tables can be just dropped from these for most applications), diffs can be applied blazingly fast on any hardware then (DELETE all the id's that were changed, COPY all the new/touched stuff - no need to query database for nodes, ways and relations). Comments? Ideas? Patches? -- Darafei Komяpa Praliaskouski OSM BY Team - http://openstreetmap.by/ xmpp:m...@komzpa.net mailto:m...@komzpa.net ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Extended diffs
Komяpa, After some time of thinking what's needed in order to keep osm2pgsql database up-to-date, I've come to idea of extended diffs. Yes, that is an excellent idea and would make processing easier for many use cases. (For some use cases it would be good if the diff contained a before and after picture - that way you could e.g. have a running count of the road lengths in some place without storing anything locally. But that might then be too voluminous.) I used to call this an augmented diff. The beauty of this is that such diffs can be issued by anyone who sets up a server for it; no need to change anything on OSMF servers. I had a brief conversation with Roland Olbricht about this who suggested that maybe his Overpass API could be fashioned into producing such diffs but I don't think anybody had really implemented anything. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Extended diffs
Would it also be possible to only include the closed changesets in the extended diffs to make it easier to make QA tools? /Jais On Thu, May 3, 2012 at 7:08 PM, Frederik Ramm frede...@remote.org wrote: Komяpa, After some time of thinking what's needed in order to keep osm2pgsql database up-to-date, I've come to idea of extended diffs. Yes, that is an excellent idea and would make processing easier for many use cases. (For some use cases it would be good if the diff contained a before and after picture - that way you could e.g. have a running count of the road lengths in some place without storing anything locally. But that might then be too voluminous.) I used to call this an augmented diff. The beauty of this is that such diffs can be issued by anyone who sets up a server for it; no need to change anything on OSMF servers. I had a brief conversation with Roland Olbricht about this who suggested that maybe his Overpass API could be fashioned into producing such diffs but I don't think anybody had really implemented anything. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 __**_ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Extended diffs
Sounds really a very good idea. @Frederik: To set-up some services on this diffs I would prefer an OSMF-Server but at the beginning we could really start with an external service. If we save time at updating the database we are able to use a more complexe database design (like IMPOSM) for higher efficient rendering. So it's perhaps also interesting for large servers. A statistic would be nice how much more traffic it would be. Greetings Kolossos ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-04-28 23:10, schrieb Jan Schejbal: I located the cause for the high CPU usage while the app is idle: Updating the compass arrow (which happens quite often) invalidates the entire map (see the sensorListener in Main.java). I'm probably not going to do anything about this, at least not until I am done with my actual task. I made a semi-fix by ensuring the map is only invalidated when the compass has changed by at lease 1 degree. I also got annoyed by a bug in the zooming logic that caused me to get caught in maximum zoom repeatedly, so I fixed it. Other than that, I have had some time, and as I didn't get any negative feedback on the general idea, I have created a prototype of the easy edit mode. For this, I have added long-press support to the VersionedGestureDetector. A long-press happens if a few hunderd milliseconds after the initial touch event, no scaling, dragging or release of the finger occurs. The listener gets informed about this, and can either chose to ignore it (return false), which means the gesture detector does nothing, or handle it (return true), which means the gesture detector will ignore any following up or drag/scale events (until the finger is released and a new touch occurs, of course). I proceeded to putting in a prototype of the easy edit mode. It currently supports creation of nodes (similar to add mode), moving nodes around (similar to movement mode), tagging (similar to tag edit mode) and deletion of nodes (similar to delete mode). It is mostly separated in its own class, which causes some weird long calling chains. The context menu handling is mostly separate. I plan on completely separating it later, and replacing the context menu with something more custom for more flexibility. I will post some mock-ups during this or next week. While this is just a first raw prototype, it should give you an insight into the look and feel of the planned EasyEdit mode. If you find time, you are welcome to have a look at the code and try it out. I appreciate any feedback you can provide. Note that you will need the ActionBarSherlock library to successfully compile the project. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
