Re: [OSM-dev] Is there a way to use simple schema without hstore
Am 20.11.2010 01:38, schrieb Brett Henderson: My best suggestion is to continue running the old Osmosis. The old version still works so don't upgrade. As Frederik suggests you can run the two versions alongside each other and pipe data between them as necessary. Maybe Andreas can port the PBF stuff to 0.36, it should be relatively isolated and as the entities didn't change, I see no blocker. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] tirex problem creating Debian/Ubuntu packages under Ubuntu 10.04
Hi, Peter Körner wrote: If you want a brand-new breaking-edge mapnik svn version, check this HowTo (german): http://wiki.openstreetmap.org/wiki/DE:HowTo_Mapnik_%26_Tirex This is a very good howto but you shouldn't claim that 0.7.1 is a brand new bleeding edge mapnik svn version - that would be 0.8.0 a.k.a. Mapnik2, and a hell of a lot more difficult to get to work on older systems. 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] tirex problem creating Debian/Ubuntu packages under Ubuntu 10.04
Am 19.11.2010 09:38, schrieb Sven Geggus: M∡rtin Koppenhoeferdieterdre...@gmail.com wrote: yes, I did this because I don't know how to get a proper package for mapnik, thank you. This should be as simple as apt-get install libmapnik-dev If you want a brand-new breaking-edge mapnik svn version, check this HowTo (german): http://wiki.openstreetmap.org/wiki/DE:HowTo_Mapnik_%26_Tirex Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Is there a way to use simple schema without hstore
Am 19.11.2010 09:58, schrieb Andreas Kalsch: One simple answer: The drivers do not work appropriately with complex SQL data types. In PHP or node.js I will get a string that I have to parse Sure, no final solution, but here's my php HStore class. Peter attachment: HStore.php ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Is there a way to use simple schema without hstore
On Sat, Nov 20, 2010 at 11:52:58AM +1100, Brett Henderson wrote: On Fri, Nov 19, 2010 at 10:50 PM, Sarah Hoffmann lon...@denofr.de wrote: On Fri, Nov 19, 2010 at 09:37:33AM +0100, Andreas Kalsch wrote: If you're applying diffs to the database you can enhance the osmosisUpdate() function (initially empty, but can be customised) to keep your separate tags tables up to date during each diff application. You will need to run the pgsql_simple_schema_0.6_action.sql script against the database so that all actions during a diff are logged and can be used by your osmosisUpdate function to know which records need to be re-processed. Is it possible to truncate the actions table for myself so that a separate script can access the changes? Simply copy away the information from the action table somewhere persistent in the osmosisUpdate function. Works fine. However, +1 from me for an action table that can be truncated manually. Is there likely to be a noticeable performance improvement in doing this? I doubt that. Compared to the entire update task, the overhead of copying is negligible. It is more a design question. I prefer to keep osmosis and the scripts for derived tables strictly apart. Doing part of the update process for derived tables in the osmosisUpdate function intermangles the two and is very difficult to debug. What was the idea behind osmosisUpdate? To allow the code to be executed within the same transaction as the changeset application? My preference if the overhead is small would be to add a contrib script to Osmosis that installs a non-truncating table that is updated by osmosisUpdate, and a customised osmosisUpdate function. It keeps the pgsql tasks simpler if I can do that. I would have expected that an implementation without update function and a persistent action table is simpler. Or do you mean, providing both variants is too complex? In that case, don't worry about it. The current osmosisUpdate does what I need and writing an apropriate function is simple. I'll just no longer think of it as a quick and dirty hack but as the proper way to do it. ;) Sarah ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Is there a way to use simple schema without hstore
Postgres is a dirty hack when you write serverside JS. But this not a problem, because it is stable and has many features. Am 21.11.10 16:43, schrieb Sarah Hoffmann: On Sat, Nov 20, 2010 at 11:52:58AM +1100, Brett Henderson wrote: On Fri, Nov 19, 2010 at 10:50 PM, Sarah Hoffmannlon...@denofr.de wrote: On Fri, Nov 19, 2010 at 09:37:33AM +0100, Andreas Kalsch wrote: If you're applying diffs to the database you can enhance the osmosisUpdate() function (initially empty, but can be customised) to keep your separate tags tables up to date during each diff application. You will need to run the pgsql_simple_schema_0.6_action.sql script against the database so that all actions during a diff are logged and can be used by your osmosisUpdate function to know which records need to be re-processed. Is it possible to truncate the actions table for myself so that a separate script can access the changes? Simply copy away the information from the action table somewhere persistent in the osmosisUpdate function. Works fine. However, +1 from me for an action table that can be truncated manually. Is there likely to be a noticeable performance improvement in doing this? I doubt that. Compared to the entire update task, the overhead of copying is negligible. It is more a design question. I prefer to keep osmosis and the scripts for derived tables strictly apart. Doing part of the update process for derived tables in the osmosisUpdate function intermangles the two and is very difficult to debug. What was the idea behind osmosisUpdate? To allow the code to be executed within the same transaction as the changeset application? My preference if the overhead is small would be to add a contrib script to Osmosis that installs a non-truncating table that is updated by osmosisUpdate, and a customised osmosisUpdate function. It keeps the pgsql tasks simpler if I can do that. I would have expected that an implementation without update function and a persistent action table is simpler. Or do you mean, providing both variants is too complex? In that case, don't worry about it. The current osmosisUpdate does what I need and writing an apropriate function is simple. I'll just no longer think of it as a quick and dirty hack but as the proper way to do it. ;) Sarah ___ 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: [josm-dev] TIFF support
On 19 nov. 2010, at 18:27, Sebastian Klein wrote:
Olivier Croquette wrote:
Hi !
When I call this code from JOSM :
String[] formats = ImageIO.getReaderFormatNames();
for (String f:formats) {
System.out.println(f);
}
It outputs tiff (lowercase, other variants like tif, TIF and TIFF
are missing).
When I run the same code a simple-hello-world-like program, it doesn't.
I tried the -verbose option of the Java VM, and it gives me :
[Loaded com.sun.imageio.plugins.tiff.TIFFImageReaderSpi from
/Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Classes/classes.jar]
The question is : what in JOSM causes the loading of this class ?
Google sais this class comes from Java Advanced Imaging (JAI) which is loaded
by the ImportImagePlugin. Hope this helps...
Thanks Sebastian, however I have the problem even when ImportImagePlugin is not
loaded.
More strangely, I have this bad TIFF handler issue when I start JOSM from the
command line, but when I start it from Eclipse (same JAR), everything works as
expected. I am investigating further.
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
