[OSM-dev] Is there a way to use simple schema without hstore
Is there a way to use simple schema in Osmosis without hstore? And why was this changed? A separate table for tags can more easily be indexed. I think it is not a good idea to use hstore because then we can drop SQL, use NoSQL for storing data and use PostGIS/Postgres for Geometry only. What do you think? Best, Andi ___ 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 18.11.2010 10:18, schrieb Andreas Kalsch: Is there a way to use simple schema in Osmosis without hstore? And why was this changed? A separate table for tags can more easily be indexed. I think it is not a good idea to use hstore because then we can drop SQL, use NoSQL for storing data and use PostGIS/Postgres for Geometry only. What do you think? Best, Andi ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev Hello Andi, You can create an index for the tags column. hstore supports gist and gin indexes and plus it saves you a m:n join. And I don't see why using hstore data type is like using NoSQL? You can still extract the tags into a seperate table, if you like of course ;-) Frank ___ 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
It's always great to try something new, but we use Postgres as the database and it is SQL, where I use tables. Somehow I feel forced to learn something I and others will not use very often. It is better to be conservative about schemas. The problem: I have written some software that heavily relies on the 0.36 simple schema. Now I have to use 0.36 and cannot use the new PBF format. It would be good to be able to choose between hstore and the old schema that did my job very well. What about GROUP BY over single hstore k/v pairs - is this possible? hstore feels like having a table inside a cell ... Am 18.11.10 14:00, schrieb Frank Broniewski: Am 18.11.2010 10:18, schrieb Andreas Kalsch: Is there a way to use simple schema in Osmosis without hstore? And why was this changed? A separate table for tags can more easily be indexed. I think it is not a good idea to use hstore because then we can drop SQL, use NoSQL for storing data and use PostGIS/Postgres for Geometry only. What do you think? Best, Andi ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev Hello Andi, You can create an index for the tags column. hstore supports gist and gin indexes and plus it saves you a m:n join. And I don't see why using hstore data type is like using NoSQL? You can still extract the tags into a seperate table, if you like of course ;-) Frank ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] tirex problem creating Debian/Ubuntu packages under Ubuntu 10.04
I tried to install tirex, but make deb stops at a certain point: ... dh_link dh_strip dh_compress dh_fixperms dh_installdeb dh_shlibdeps dpkg-shlibdeps: Fehler: Keine Abhängigkeitsinformationen für /usr/local/lib/libmapnik.so.0.7 (verwendet von debian/tirex-backend-mapnik/usr/lib/tirex/backends/mapnik) gefunden. dh_shlibdeps: dpkg-shlibdeps -Tdebian/tirex-backend-mapnik.substvars debian/tirex-backend-mapnik/usr/lib/tirex/backends/mapnik returned exit code 2 make: *** [binary-arch] Fehler 9 dpkg-buildpackage: Fehler: fakeroot debian/rules binary gab Fehler-Exitstatus 2 debuild: fatal error at line 1340: dpkg-buildpackage -rfakeroot -D -us -uc -I failed make: *** [deb] Fehler 29 there is a link /usr/local/lib/libmapnik.so.0.7 pointing to libmapnik.so.0.7.1 mo...@acermartin:~$ ls -l /usr/local/lib/ lrwxrwxrwx 1 root root 16 2010-10-11 19:09 libmapnik.so - libmapnik.so.0.7 lrwxrwxrwx 1 root root 18 2010-10-11 19:09 libmapnik.so.0.7 - libmapnik.so.0.7.1 -rwxr-xr-x 1 root root 2033792 2010-10-11 18:59 libmapnik.so.0.7.1 Do you know what could be the problem? cheers, Martin ___ 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, M∡rtin Koppenhoefer wrote: Do you know what could be the problem? Next time you post a problem to an international list, it will certainly help to do a export LANG=C before you run the command, that would make the error messages appear in English. Your probelm seems to be that you are trying to build a Debian package for Tirex, but you have installed Mapnik outside the Debian packaging mechanism (i.e. with scons install or something like that). Either install Tirex in the same way (make install), or remove your Mapnik installation and replace it by one that comes from a proper package. 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
2010/11/18 Frederik Ramm frede...@remote.org: thank you for your help. Next time you post a problem to an international list, it will certainly help to do a export LANG=C before you run the command, that would make the error messages appear in English. Thanks, I was aware that German error messages wouldn't be too helpful for many of the readers here, but I wasn't aware of how to change this (I am using Linux for roughly a year now, so I'd say I'm still almost a newbie). Your probelm seems to be that you are trying to build a Debian package for Tirex, but you have installed Mapnik outside the Debian packaging mechanism (i.e. with scons install or something like that). yes, I did that some time ago... Either install Tirex in the same way (make install) yes, I did this because I don't know how to get a proper package for mapnik, thank you. Maybe not the best way, but as soon as I learned more about package management, I'll probably change this. Cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Mapnik / General question on projection
First I must admit that I don't know much about projections, reference systems and geodetic datums. I have recently experimented with homemade hillshading and contours, and I found out by trying that my hillshade was fitting the contours if I assumed it was in EPSG 3785 (I created the hillshading from SRTM with Grass GIS and reprojected to an EPSG 900913 setting while the contours were created with mapnik and srtm2osm). By reading the EPSG documentation sheets it seems that 3785 and 3857 are not the same (the first uses a sphere, while the latter uses an ellipsoid with inverse flattening of 298.257223563). EPSG says that the ellipsoid-version is valid (and registered as 3857) while the sphere is not. This results visually in quite some change on the map if you mix it up. Therefor I thought that Mapnik's 900913 was equal to EPSG's non-valid 3785 version with the sphere. (EPSG states: Sphere with radius equal to the semi-major axxis of the GRS80 and WGS84 ellipsoids. Used only for Web approximate mapping and visualisation. Not recognised by geodetic authorities --- on which I found some comments (EPSG is arrogant) in the web btw. who said it was perfectly working with the sphere as well, even if not scientifically correct). Now I found some docs in the OSM-Wiki that state we were using EPSG 3857. My own tests indicate we are using the (not registered) 3785 (sphere). Also this setting in mapnik/inc/entities.xml.inc indicates this: !ENTITY srs900913 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over in generate_image.py I found this (seems that someone changed from sphere to ellipsoid): # prj = mapnik.Projection(+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over) prj = mapnik.Projection(+proj=merc +a=6378137 +rf=298.257223563 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over) can someone please tell me which datum is used by the mapnik and t...@h tile servers? cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik / General question on projection
On Thu, Nov 18, 2010 at 5:58 PM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: First I must admit that I don't know much about projections, reference systems and geodetic datums. I have recently experimented with homemade hillshading and contours, and I found out by trying that my hillshade was fitting the contours if I assumed it was in EPSG 3785 (I created the hillshading from SRTM with Grass GIS and reprojected to an EPSG 900913 setting while the contours were created with mapnik and srtm2osm). By reading the EPSG documentation sheets it seems that 3785 and 3857 are not the same (the first uses a sphere, while the latter uses an ellipsoid with inverse flattening of 298.257223563). EPSG says that the ellipsoid-version is valid (and registered as 3857) while the sphere is not. This results visually in quite some change on the map if you mix it up. Therefor I thought that Mapnik's 900913 was equal to EPSG's non-valid 3785 version with the sphere. (EPSG states: Sphere with radius equal to the semi-major axxis of the GRS80 and WGS84 ellipsoids. Used only for Web approximate mapping and visualisation. Not recognised by geodetic authorities --- on which I found some comments (EPSG is arrogant) in the web btw. who said it was perfectly working with the sphere as well, even if not scientifically correct). Now I found some docs in the OSM-Wiki that state we were using EPSG 3857. My own tests indicate we are using the (not registered) 3785 (sphere). Also this setting in mapnik/inc/entities.xml.inc indicates this: !ENTITY srs900913 +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over in generate_image.py I found this (seems that someone changed from sphere to ellipsoid): # prj = mapnik.Projection(+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over) prj = mapnik.Projection(+proj=merc +a=6378137 +rf=298.257223563 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over) can someone please tell me which datum is used by the mapnik and t...@h tile servers? I'm totally confused by your email, so bear with me. As far as I'm aware, 900913, 3785 and 3857 are all identical, and don't have the difference that you are describing above. From spatialreference.org http://www.spatialreference.org/ref/epsg/3785/ http://www.spatialreference.org/ref/epsg/3785/proj4/ http://spatialreference.org/ref/sr-org/6864/ (EPSG:3857) http://spatialreference.org/ref/sr-org/6864/proj4/ From the proj4 project: http://trac.osgeo.org/proj/browser/trunk/proj/nad/epsg Moreover, you refer to changes made to the generate_image.py file, but I don't see such a change: http://trac.openstreetmap.org/browser/applications/rendering/mapnik/generate_image.py#L38 However, the following two entries at EPSG are conflicting with all the above, and do in fact appear to be different: http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3785reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3785 http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3857reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3857 Ho hum. Maybe take it up with the proj project? Anyway, we use Spherical Mercator ie. the one without the +rf=298.25... so I'd find a different copy of generate_image.py Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New public nominatim service (mapquest)
I think you saw my attempt at a more interactive search box? If you want, I can send you the code or have it imported in the OSM SVN. http://lima.schaaltreinen.nl/mvexel/nominatim/ Best martijn van exel +++ m...@rtijn.org laziness - impatience - hubris http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes On Wed, Nov 17, 2010 at 9:48 PM, Wyo otto.w...@orpatec.ch wrote: Brian Quinion wrote: Mapquest have now created an instance of nominatim running on their network infrastructure Does Mapquest also have a nice sample page which shows how to access Nominatim? I'd like to access Nominatim via OpenLayers.Request if possible, yet I'm not very familiar with OpenLayers and such samples seems to be rather rare. So far I've just succeeded with setting up a demo map page with some small improvements ( http://www.orpatec.ch/osm/tools/main.php). Accessing Nominatim seems to be in yet another ligue. Wyo ___ 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] Mapnik / General question on projection
2010/11/18 Andy Allan gravityst...@gmail.com: As far as I'm aware, 900913, 3785 and 3857 are all identical, and don't have the difference that you are describing above. From spatialreference.org From the proj4 project: Moreover, you refer to changes made to the generate_image.py file, but I don't see such a change: http://trac.openstreetmap.org/browser/applications/rendering/mapnik/generate_image.py#L38 yes, sorry, this was probably part of my own tests (and as I used primarily generate_tiles it didn't harm). However, the following two entries at EPSG are conflicting with all the above, and do in fact appear to be different: http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3785reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3785 http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3857reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3857 yes, I also found that proj4 treats them equally, but in the end I thought it would be the best to rely on EPSG for issues on EPSG... Ho hum. Maybe take it up with the proj project? Anyway, we use Spherical Mercator ie. the one without the +rf=298.25... so I'd find a different copy of generate_image.py Thanks for clarifying this. I think we should write this in the wiki (basically we shouldn't write that we are using EPSG 3857 but we could stick to 900913) , as you get (obviously) different results with and without the ellipsoid. It is quite confusing indeed, but maybe I was wrong with the 3785 / 3857 idea: I found out that EPSG themselves has 2 versions of EPSG 3857: one is not valid (and identical to what before they called 3785) and one is valid (according to EPSG) which has the ellipsoid with inverse flattening. cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New public nominatim service (mapquest)
Martijn van Exel wrote: I think you saw my attempt at a more interactive search box? If you want, I can send you the code or have it imported in the OSM SVN. Ahh, that was you, yes I saw it. Well I'd really like to know how to do it with OpenLayers.Request, so your code probably won't help. http://lima.schaaltreinen.nl/mvexel/nominatim/ Nice, yet either Nominatim or your code or both don't show usable results. E.g. if I search for London I've almost to type the full name. Wyo ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New public nominatim service (mapquest)
The search box on the left does not work because the demo is not a full implementation of the main page. (On my to do list). After enabling the routing layer, you can search for London. http://nroets.dev.openstreetmap.org/demo/index.html?layers=B000FTFTT Which unfortunately returns London in Ontario, Canada, which is the first entry of the list returned by Nominatim. Ideally cities should be listed in decreasing population size. Not a big job considering the data is in the geonames database. On Thu, Nov 18, 2010 at 9:14 PM, Wyo otto.w...@orpatec.ch wrote: Nic Roets wrote: I think nominatim is well documented on the wiki. Nomination well yes, but not how to access Nomination with Ajax. I used it to create the Osm.org routing demo. It queries nominatim using jquery. You can find the source here: http://nroets.dev.openstreetmap.org/ Thanks. I tried the demos, searching for london, none produced any results. Wyo ___ 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] New public nominatim service (mapquest)
On Thu, Nov 18, 2010 at 8:57 PM, Wyo otto.w...@orpatec.ch wrote: Martijn van Exel wrote: I think you saw my attempt at a more interactive search box? If you want, I can send you the code or have it imported in the OSM SVN. Ahh, that was you, yes I saw it. Well I'd really like to know how to do it with OpenLayers.Request, so your code probably won't help. http://lima.schaaltreinen.nl/mvexel/nominatim/ Nice, yet either Nominatim or your code or both don't show usable results. E.g. if I search for London I've almost to type the full name. That is Nominatim not matching partial names. It was not designed for this kind of AJAXy operation apparently. As it is the demo is not very friendly to nominatim, firing a request after every change made in the input field. Subsequent requests seem to cancel the predecessors, but I guess the harm on the server side is already done by then. Wyo martijn van exel +++ m...@rtijn.org laziness - impatience - hubris http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Minutely Mapnik
Hi all, Does the process of applying minutely updates only work when the initial planet was a full planet, not an extract? Is it possible to do this on extracts? Best Martijn martijn van exel +++ m...@rtijn.org laziness - impatience - hubris http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Minutely Mapnik
Hi, Martijn van Exel wrote: Does the process of applying minutely updates only work when the initial planet was a full planet, not an extract? Is it possible to do this on extracts? Yes (use the bounding box filter on osm2pgsql), but there will be some fuzziness around the edges. I forgot what exactly it was, but there will be some cases where a node is moved from the inside to the outside or so where things foul up. 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] Minutely Mapnik
On 18/11/2010 21:24, Frederik Ramm wrote: I forgot what exactly it was, but there will be some cases where a node is moved from the inside to the outside or so where things foul up. The usual example is: * Way and all nodes fall outside initial bounding box of extract * One or more nodes of the way are moved inside the bounding box, but the way itself isn't changed * Way should now appear in bounding box, but doesn't. One workaround is to maintain an extract larger than you need, apply the diffs to that, then extract the true area you need. Not foolproof, but less likely to screw up. -- Jonathan (Jonobennett) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.
On 16-10-2010 9:55, Lennard wrote: On 16-10-2010 8:39, Brett Henderson wrote: If anybody sees any issues with the binary support, please let Scott and I know. I'm now building Osmosis via an automated Hudson process so pushing out new builds should be fairly quick once a fix is identified. Scott already knows about this, but 23580[1] will emit a warning for every occurence of an object without user/uid parameters. These objects, the result of anonymous edits which were possible in the past, do exist in the planet, and could cause some flooding on the console output. In my eyes, this change should be reverted. Just built the current trunk, and this output[1] is still present. Could you please consider removing this notice, or only output it once instead of for every anonymous element? In fact, the suggestion being given is plain incorrect for some uses. For instance, when you're cutting out a piece of the planet, you're probably intending to distribute that extract as-is, i.e. with all metadata intact. The suggestion in that respect is too bold. [1] Attention: Data being output lacks metadata. Please use omitmetadata=true -- Lennard ___ 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
Hi Andreas, The change was made mostly for performance reasons. With a full planet imported into the database, bounding box style queries are now approximately 10 times faster. This is due to a couple of reasons: - All data (with the exception of relations) is now clustered by geographical location. This drastically improves performance where data is being processed for a limited area. - The nodes and ways tables are the only tables that have a geometry column, thus other data must be embedded in those tables in order to make use of clustering. I don't understand your comment regarding NoSQL. The main change is that now you will have to deal with a more complex hstore column type on the nodes/ways tables, but otherwise the same data still exists and can still be manipulated with SQL statements. The data is less relational that it was previously, but tag data is not terribly useful without access to parent entities so grouping them together shouldn't result in loss of functionality. You can still populate separate tags tables if you wish by running your own separate query to pull the hstore column apart. 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. The older Osmosis 0.36 is still available so you don't have to upgrade. It remains compatible with 0.6 XML files. Finally, if there is enough demand for the older schema style the old tasks can be pulled back out of SVN and run alongside the new ones, but I'm not keen to do that without good reason. I did consider trying to support both styles of table in the same tasks by dynamically detecting what tables are installed, but it increases the code complexity considerably and I didn't think the effort was worthwhile. Finally, I didn't make the change without careful consideration. I do try to keep schemas stable, and when they do change I provide an upgrade script to allow migration between them. But the performance gains achieved through use of hstore were too great to ignore. Retrieving heavily populated 1x1 degree areas from a database containing a full planet used to take approximately 1 hour, but this is now down to well under 10 minutes. Hope that helps, Brett On Thu, Nov 18, 2010 at 8:18 PM, Andreas Kalsch andreaskal...@gmx.dewrote: Is there a way to use simple schema in Osmosis without hstore? And why was this changed? A separate table for tags can more easily be indexed. I think it is not a good idea to use hstore because then we can drop SQL, use NoSQL for storing data and use PostGIS/Postgres for Geometry only. What do you think? Best, Andi ___ 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] OSM binary format (pbf) 1.0 is in osmosis trunk.
On 18-11-2010 23:47, Lennard wrote: Just built the current trunk, and this output[1] is still present. Could you please consider removing this notice, or only output it once instead of for every anonymous element? I seem to have missed the fact that it will print upto 100 times this message and then no more. Ah well, that'll do, I guess. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.
On Thu, Nov 18, 2010 at 4:47 PM, Lennard l...@xs4all.nl wrote: On 16-10-2010 9:55, Lennard wrote: On 16-10-2010 8:39, Brett Henderson wrote: If anybody sees any issues with the binary support, please let Scott and I know. I'm now building Osmosis via an automated Hudson process so pushing out new builds should be fairly quick once a fix is identified. Scott already knows about this, but 23580[1] will emit a warning for every occurence of an object without user/uid parameters. These objects, the result of anonymous edits which were possible in the past, do exist in the planet, and could cause some flooding on the console output. In my eyes, this change should be reverted. Just built the current trunk, and this output[1] is still present. Could you please consider removing this notice, or only output it once instead of for every anonymous element? I think that the notice should exist. There's an edge case where someone feeds a file with stripped metadata into osmosis, but, on the output, forgets to tell the pbf writer to strip metadata. I could invisibly have the serializer happily write the junk timestamps, version numbers and other metadata fields, but I thought that the user probably didn't intend to do that. The problem is that there are some entities in the database that do have junk metadata (??), so the warning false positives. I didn't encounter this case in my testing. I won't object to different text, if you have want to propose a patch: Attention, some entities in the file appear to lack metadata. Did you intend to use omitmetadata=true? Scott In fact, the suggestion being given is plain incorrect for some uses. For instance, when you're cutting out a piece of the planet, you're probably intending to distribute that extract as-is, i.e. with all metadata intact. The suggestion in that respect is too bold. [1] Attention: Data being output lacks metadata. Please use omitmetadata=true ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] TIFF support
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 ?
It's causing problems here, because it doesn't seem to be able to load any tiff
file anyway.
Thanks for your help !
Best regards
Olivier
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
