Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data
2009/1/19 Christopher Schmidt crschm...@metacarta.com Hey, Using the osm2pgsql diff loading code, and osmosis's --rci, I've got an up to date copy of the Mapnik database being maintained on a server I have access to. I put together a little bookmarklet that lets you do a 'live view' of any area by pressing a button. http://labs.metacarta.com/osm/up-to-date/ Since this is not tiled at all, the performance is not likely to be great, but it does make an interesting demo. As usual, the data is working from osmosis minutely diffs, so it will be delayed in the same way those are. For the record, loading daily diffs took about one hour apiece (after spending the 10.5 hours to get a planet loaded). (Range was from 45m to 70m; the latter was during a vaccum run, I believe.) All in all, a pretty simple task; just load a planet, load diffs with -a -- I did this manually to get caught up to the latest hour -- then turn on --rci. Feedback welcome, One quick note... It looks like UTF8 data has been broken at some point... example of area that this is visible below... http://www.informationfreeway.org/?lat=30.287874917085606lon=120.12903655645077zoom=16layers=F0F0B0F Apart from that little problem it looks pretty cool... Of course, if the mapnik layer was getting minutely diffs applied along with automatic marking of tiles with changes as dirty, that would be even cooler :) d ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data
Hi, D Tucny wrote: One quick note... It looks like UTF8 data has been broken at some point... I guess that's what is meant by potential gotchas at the bottom of the Minutely Mapnik page: When creating your database, make sure you specify the encoding as utf-8, otherwise you will get crappy encoding issues. (This is currently the case for the Up-to-Date DB: I'll probably wait until the new planet is out, and update it after it comes out.) Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data
2009/1/19 Frederik Ramm frede...@remote.org Hi, D Tucny wrote: One quick note... It looks like UTF8 data has been broken at some point... I guess that's what is meant by potential gotchas at the bottom of the Minutely Mapnik page: When creating your database, make sure you specify the encoding as utf-8, otherwise you will get crappy encoding issues. (This is currently the case for the Up-to-Date DB: I'll probably wait until the new planet is out, and update it after it comes out.) Ahh, hadn't read that page yet, thanks Frederik... d ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data
Christopher Schmidt crschm...@metacarta.com writes: Using the osm2pgsql diff loading code, and osmosis's --rci, I've got an up to date copy of the Mapnik database being maintained on a server I have access to. I put together a little bookmarklet that lets you do a 'live view' of any area by pressing a button. http://labs.metacarta.com/osm/up-to-date/ Sounds great :-) Here's a video of how it also really works here: http://iki.fi/lindi/osm/up-to-date1.ogv ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Schmidt wrote: http://wiki.openstreetmap.org/wiki/Minutely_Mapnik is a handful of notes on what I did to get it started; I'm happy to elaborate if people want to ask questions. (Please feel free to CC me on responses, as I don't receive dev emails by default, though I'll check the archives for replies I miss.) This is great, but this area seems to have the wrong background color in the up to date version of the map: http://www.openstreetmap.org/?lat=-25.26093lon=-57.56588zoom=15 Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl0dIcACgkQz+aYVHdncI3jbACfb9Y0337lpK60/qRyvaHeD/Fo ZGEAn0+F0uJ2dkI/hvx78A9Ovc5QBJd4 =ROev -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] [PATCH] geotagged images
Hi, i made a patch for the long outstanding bug #440, that geotaged images are unusable after an other layer is added or removed. It is attached to the bug and it would be nice, if someone can review it. Cheers, detlef ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Who is xeen
Hello, who is the xeen of Bugtracker? Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data
On Mon, Jan 19, 2009 at 1:43 PM, Christopher Schmidt crschm...@metacarta.com wrote: The up to date map has a different background color. There are two reasons for this: 1. I don't really have any clue what coastline data I'm supposed to be using, and without that, the map is going to look different no matter what I do. 2. I wanted something to differentiate between the main map and Up-to-Date; I chose the slight background color difference. Which hardware are you running this on? Can we get some specs (disks, processor, ram)? -S ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] [PATCH] slippy_map_chooser plugin forgets map style
Hi, I've made a patch for the slippy_map_chooser plugin, that it remembers the mapstyle a user has chosen. Till now with every open of the download dialog it falls back to the mapnik style. The patch is attached to bug #2020 and it would be nice, if someone can review it. Cheers, detlef ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [PATCH] geotagged images
Am Montag, den 19.01.2009, 13:56 +0100 schrieb Dirk Stöcker: But when you are sure you fixed the problem(s), then please close all related geotagged reports. Hi, after some feedback from someone who uses it, I will close all related bugs. Cheers, detlef ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] new fixme-like check for keepright.ipax.at and alike
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jochen Topf wrote: On Fri, Jan 16, 2009 at 10:10:54PM +0100, Harald Kleiner wrote: So to recapitulate this topic it seems consensus to me that using name=tbd or ref=tbd is undesirable and I can easily integrage it in my fixme-check to highlight spots where this tagging has been used The problem is: If you add a check for name=tbd etc. to your script we are running into exactly the problem I have been describing, namely People *will* use it, because you script so handily highlightes those cases which is what they want. But you will only check for tbd, somebody else uses unknown instead and asks you to add this to your script also ad infinitum... I am guilty of this myself, I added a check for anything=*FIXME* to OSM Inspector and now ask myself whether I should have done this. Our checks help people remove those cases from the tags but they also encourage more and more people to actually uses those special values. I don't known how to solve this... :-( I think the only way is to write a bot to retag [thing]=FIXME as FIXME=[thing] and name=tbd as FIXME=name tbd etc. I know that bots are a touchy subject, but I think we need clear out deprecated and wrong stuff, otherwise interpreting the data will just get horrendous. It just occurred to me that it might be useful to make 2 kinds of FIXME, one for when a ground survey / local knowledge is required, and another for when anyone with expertise could fix the tagging. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl0gU8ACgkQz+aYVHdncI1a7ACgtUYrv7ZGuWK9tWUZhR+WqDAf R8gAn2TBE9oGTkqwhYa0RDzshBy8k0qT =1x3Y -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile and renderd .. why 404?
On 19 Jan 2009, at 17:51, Mikel Maron wrote: Hi all Trying to get a long suffering mapnik/mod_tile install up and running. Have the latest from SVN. Everything builds and installs without error. renderd and apache+mod_tile start up fine. But when I request a tile, getting a 404. Before I start digging around, does anyone have advice on what might possibly be missing? Look at your apache error log, it will more than likely tell you. -- Chris Jones, SUCS Admin http://sucs.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile and renderd .. why 404?
Look at your apache error log, it will more than likely tell you. File does not exist: /var/www/osm_tiles2/0 It seems like whatever hook mod_tile is using to grab these requests isn't catching...___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile and renderd .. why 404?
On Mon, 2009-01-19 at 10:43 -0800, Mikel Maron wrote: Look at your apache error log, it will more than likely tell you. File does not exist: /var/www/osm_tiles2/0 It seems like whatever hook mod_tile is using to grab these requests isn't catching... Check the readme.txt The mod_tile code was updated a couple of weeks ago to add support for multiple layers. It now requires a config file to tell it what layers and URIs to map. The default tile storage location also moved to /var/lib/mod_tile/layer_name/... Jon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile and renderd .. why 404?
Check the readme.txt The mod_tile code was updated a couple of weeks ago to add support for multiple layers. It now requires a config file to tell it what layers and URIs to map. The default tile storage location also moved to /var/lib/mod_tile/layer_name/... Yup, have this code. renderd.conf is in place. /var/lib/mod_tile/Default/ exists... -Mikel___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] mod_tile and renderd .. why 404?
On Mon, 2009-01-19 at 12:23 -0800, Mikel Maron wrote: Check the readme.txt The mod_tile code was updated a couple of weeks ago to add support for multiple layers. It now requires a config file to tell it what layers and URIs to map. The default tile storage location also moved to /var/lib/mod_tile/layer_name/... Yup, have this code. renderd.conf is in place. /var/lib/mod_tile/Default/ exists... How about the Apache config. I have a file which contains: LoadModule tile_module modules/mod_tile.so AddTileConfig /osm_tiles2/ Default LoadTileConfig /etc/renderd.conf The other obvious question is whether you've done: make clean, make all, sudo make install, /etc/init.d/apache restart If that all looks good, try emailing me the apache config renderd.conf Jon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 'Up-to-Date', serving ondemand live Mapnik data
On Mon, Jan 19, 2009 at 8:31 AM, D Tucny d...@tucny.com wrote: 2009/1/19 Christopher Schmidt crschm...@metacarta.com Since this is not tiled at all, the performance is not likely to be great, but it does make an interesting demo. Apart from that little problem it looks pretty cool... Of course, if the mapnik layer was getting minutely diffs applied along with automatic marking of tiles with changes as dirty, that would be even cooler :) this script (currently hourly) can be very easily adapted to expire metatiles based on minutely diffs: http://svn.openstreetmap.org/applications/utils/export/tile_expiry/ cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Webstart ?
Hello, in #390 there has been some activity to provide a webstart version of JOSM. Is there some work going in that direction ? I might help on this, or if no work in progress exists take over this task. André smime.p7s Description: S/MIME Cryptographic Signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] LatLon.greatCircleDistance Bug?
Hi, I stumbled over a possible bug in the greatCircleDistance calculation of the LatLon class. If you zoom out in JOSM so that the MapScale gets beyond aprox 430 kilometers, the shown value will get _lower_. I think, that it is a bug in the greatCircleDistance calculation, cause if you zoom further out, at some point the map icons and the names of the icons will reappear. They disappear quite early for me, because I have set mappaint.showicons=400 mappaint.shownames=50. And the greatCircleDistance method is the only one I found, which is involved in MapScaler and MapPaintVisitor in respect to this strange behaviour. Cheers, detlef ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] LatLon.greatCircleDistance Bug?
Hi Detlef, Detlef Reichl schrieb: I stumbled over a possible bug in the greatCircleDistance calculation of the LatLon class. If you zoom out in JOSM so that the MapScale gets beyond aprox 430 kilometers, the shown value will get _lower_. I think, that it is a bug in the greatCircleDistance calculation, cause if you zoom further out, at some point the map icons and the names of the icons will reappear. They disappear quite early for me, because I have set mappaint.showicons=400 mappaint.shownames=50. And the greatCircleDistance method is the only one I found, which is involved in MapScaler and MapPaintVisitor in respect to this strange behaviour. can you give me the lines and filenames? Best, Tobias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] LatLon.greatCircleDistance Bug?
Am Montag, den 19.01.2009, 16:47 +0100 schrieb Tobias Wendorff: Detlef Reichl schrieb: I stumbled over a possible bug in the greatCircleDistance calculation of the LatLon class. If you zoom out in JOSM so that the MapScale gets beyond aprox 430 kilometers, the shown value will get _lower_. I think, that it is a bug in the greatCircleDistance calculation, cause if you zoom further out, at some point the map icons and the names of the icons will reappear. They disappear quite early for me, because I have set mappaint.showicons=400 mappaint.shownames=50. And the greatCircleDistance method is the only one I found, which is involved in MapScaler and MapPaintVisitor in respect to this strange behaviour. can you give me the lines and filenames? Hi Tobias, src/org/openstreetmap/josm/gui/MapScaler.java line 30 src/org/openstreetmap/josm/data/osm/visitor/MapPaintVisitor.java line 1197 Cheers, detlef ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] LatLon.greatCircleDistance Bug?
Hi Detlef, Detlef Reichl schrieb: src/org/openstreetmap/josm/gui/MapScaler.java line 30 src/org/openstreetmap/josm/data/osm/visitor/MapPaintVisitor.java line 1197 even if I don't like the spherical law of cosines formula, it's done correctly: src/org/openstreetmap/josm/data/coor/LatLon.java line 106 Perhaps, someone could change the radius to 6378137 (WGS84 equatorial radius) or 6371000 (geometric mean radius of WGS84). The bug must be in the other parts. Sorry, I just started with JOSM ... Tried to open a TRAC? Best regards, Tobias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] LatLon.greatCircleDistance Bug?
Am Montag, den 19.01.2009, 17:15 +0100 schrieb Tobias Wendorff: Hi Tobias, The bug must be in the other parts. I'm a little step further. Form the MapScaller class i printed out the ll1, ll2 and dist value to the console. It looks like this: ll1 64.5635383519239 : -19.701032734051942 ll2 64.5635383519239 : -9.890120706057816 dist 468619.7921204448 ll1 65.91688367961092 : -22.856876103056717 ll2 65.91688367961092 : -11.955862738618798 dist 494557.8424123941 ll1 67.34105605688401 : -26.363368735284247 ll2 67.34105605688401 : -14.251131663686559 dist 518612.50496088184 ll1 68.82977522568474 : -30.259471659981504 ll2 68.82977522568474 : -16.801430469317406 dist 539957.2886111567 ll1 70.3743573179418 : -34.58847490964512 ll2 70.3743573179418 : -19.635095808907234 dist 557687.3702770402 ll1 71.963536631957 : -39.398478520382476 ll2 71.963536631957 : -22.783612852895935 dist 570850.2680160615 ll1 73.58339022047235 : -44.74292697675731 ll2 73.58339022047235 : -26.281965123994485 dist 578490.4937988957 ll1 75.21740411282117 : -50.681203039396024 ll2 75.21740411282117 : -30.169023202992882 dist 579708.5723878946 ll1 76.84671859283488 : -57.27928755343901 ll2 76.84671859283488 : -34.487976624102195 dist 573732.9917813947 ll1 78.45058287944866 : -64.61049256904235 ll2 78.45058287944866 : -39.28681375866812 dist 560001.2842969369 ll1 80.00703564250523 : -72.75627591971273 ll2 80.00703564250523 : -44.61885501929692 dist 538243.7455625333 ll1 81.49380667414835 : -81.80714630934649 ll2 81.49380667414835 : -50.54334530888447 dist 508560.6560124746 ll1 82.88940754706157 : -91.86366896449512 ll2 82.88940754706157 : -57.12611229731509 dist 471481.77217010665 ll1 84.17434746547553 : -103.03758302577135 ll2 84.17434746547553 : -64.44029784001577 dist 427995.86036005936 Up to a longitude difference of aprox 20 degrees it looks fine. The strange thing is, I copied the calculation to a small test program and feed it with similar data and that worked like expected :-/ I think that needs an expert ;-) Sorry, I just started with JOSM ... Me too (on the code side). Tried to open a TRAC? I don't like to open a bug with there is a bug, but i don't know where... Cheers, detlef ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] LatLon.greatCircleDistance Bug?
On Mon, Jan 19, 2009 at 8:34 AM, Detlef Reichl detlef.rei...@gmx.orgwrote: Am Montag, den 19.01.2009, 17:15 +0100 schrieb Tobias Wendorff: Hi Tobias, The bug must be in the other parts. I'm a little step further. Form the MapScaller class i printed out the ll1, ll2 and dist value to the console. It looks like this: ll1 64.5635383519239 : -19.701032734051942 ll2 64.5635383519239 : -9.890120706057816 dist 468619.7921204448 ll1 65.91688367961092 : -22.856876103056717 ll2 65.91688367961092 : -11.955862738618798 dist 494557.8424123941 ll1 67.34105605688401 : -26.363368735284247 ll2 67.34105605688401 : -14.251131663686559 dist 518612.50496088184 ll1 68.82977522568474 : -30.259471659981504 ll2 68.82977522568474 : -16.801430469317406 dist 539957.2886111567 ll1 70.3743573179418 : -34.58847490964512 ll2 70.3743573179418 : -19.635095808907234 dist 557687.3702770402 ll1 71.963536631957 : -39.398478520382476 ll2 71.963536631957 : -22.783612852895935 dist 570850.2680160615 ll1 73.58339022047235 : -44.74292697675731 ll2 73.58339022047235 : -26.281965123994485 dist 578490.4937988957 ll1 75.21740411282117 : -50.681203039396024 ll2 75.21740411282117 : -30.169023202992882 dist 579708.5723878946 ll1 76.84671859283488 : -57.27928755343901 ll2 76.84671859283488 : -34.487976624102195 dist 573732.9917813947 ll1 78.45058287944866 : -64.61049256904235 ll2 78.45058287944866 : -39.28681375866812 dist 560001.2842969369 ll1 80.00703564250523 : -72.75627591971273 ll2 80.00703564250523 : -44.61885501929692 dist 538243.7455625333 ll1 81.49380667414835 : -81.80714630934649 ll2 81.49380667414835 : -50.54334530888447 dist 508560.6560124746 ll1 82.88940754706157 : -91.86366896449512 ll2 82.88940754706157 : -57.12611229731509 dist 471481.77217010665 ll1 84.17434746547553 : -103.03758302577135 ll2 84.17434746547553 : -64.44029784001577 dist 427995.86036005936 Up to a longitude difference of aprox 20 degrees it looks fine. The strange thing is, I copied the calculation to a small test program and feed it with similar data and that worked like expected :-/ I think that needs an expert ;-) Sorry, I just started with JOSM ... Me too (on the code side). Tried to open a TRAC? I don't like to open a bug with there is a bug, but i don't know where... Cheers, detlef I spot-checked a couple examples that you posted against an online great circle calculator and they appear to be correct (assuming your format is II1 latitude : longitude). Remember that at higher latitudes, one degree of longitude is a shorter distance than it is at the equator. So, if the greatCircleDistance function is okay, maybe it's the arguments that are being passed to the function that need to be checked. Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] LatLon.greatCircleDistance Bug?
On Mon, Jan 19, 2009 at 9:03 AM, Karl Newman siliconfi...@gmail.com wrote: On Mon, Jan 19, 2009 at 8:34 AM, Detlef Reichl detlef.rei...@gmx.orgwrote: Am Montag, den 19.01.2009, 17:15 +0100 schrieb Tobias Wendorff: Hi Tobias, The bug must be in the other parts. I'm a little step further. Form the MapScaller class i printed out the ll1, ll2 and dist value to the console. It looks like this: ll1 64.5635383519239 : -19.701032734051942 ll2 64.5635383519239 : -9.890120706057816 dist 468619.7921204448 ll1 65.91688367961092 : -22.856876103056717 ll2 65.91688367961092 : -11.955862738618798 dist 494557.8424123941 ll1 67.34105605688401 : -26.363368735284247 ll2 67.34105605688401 : -14.251131663686559 dist 518612.50496088184 ll1 68.82977522568474 : -30.259471659981504 ll2 68.82977522568474 : -16.801430469317406 dist 539957.2886111567 ll1 70.3743573179418 : -34.58847490964512 ll2 70.3743573179418 : -19.635095808907234 dist 557687.3702770402 ll1 71.963536631957 : -39.398478520382476 ll2 71.963536631957 : -22.783612852895935 dist 570850.2680160615 ll1 73.58339022047235 : -44.74292697675731 ll2 73.58339022047235 : -26.281965123994485 dist 578490.4937988957 ll1 75.21740411282117 : -50.681203039396024 ll2 75.21740411282117 : -30.169023202992882 dist 579708.5723878946 ll1 76.84671859283488 : -57.27928755343901 ll2 76.84671859283488 : -34.487976624102195 dist 573732.9917813947 ll1 78.45058287944866 : -64.61049256904235 ll2 78.45058287944866 : -39.28681375866812 dist 560001.2842969369 ll1 80.00703564250523 : -72.75627591971273 ll2 80.00703564250523 : -44.61885501929692 dist 538243.7455625333 ll1 81.49380667414835 : -81.80714630934649 ll2 81.49380667414835 : -50.54334530888447 dist 508560.6560124746 ll1 82.88940754706157 : -91.86366896449512 ll2 82.88940754706157 : -57.12611229731509 dist 471481.77217010665 ll1 84.17434746547553 : -103.03758302577135 ll2 84.17434746547553 : -64.44029784001577 dist 427995.86036005936 Up to a longitude difference of aprox 20 degrees it looks fine. The strange thing is, I copied the calculation to a small test program and feed it with similar data and that worked like expected :-/ I think that needs an expert ;-) Sorry, I just started with JOSM ... Me too (on the code side). Tried to open a TRAC? I don't like to open a bug with there is a bug, but i don't know where... Cheers, detlef I spot-checked a couple examples that you posted against an online great circle calculator and they appear to be correct (assuming your format is II1 latitude : longitude). Remember that at higher latitudes, one degree of longitude is a shorter distance than it is at the equator. So, if the greatCircleDistance function is okay, maybe it's the arguments that are being passed to the function that need to be checked. Karl I just had a quick look, and in both occurrences, it appears the distance is calculated based on the coordinates of a 100 pixel long horizontal line with its origin at the upper left corner. So, that would make sense why the distance goes down as you zoom out because the latitude is increasing so the line is becoming shorter. Probably it should be based on the diagonal distance of the viewport, or at the least, the origin of the 100-pixel line should be at the center of the viewport. Karl ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Another Java version conflict
Hi List,
there is again an error in the sources which only occurs in Java 5 but is fine
in Java 6. Since the compile server runs on Java 5 it does not build a new
JAR for downloading.
Here is the error message:
$ ant dist
Buildfile: build.xml
init:
[mkdir] Created dir: /home/hinrichs/projekte/josm/build
[mkdir] Created dir: /home/hinrichs/projekte/josm/dist
compile:
[javac] Compiling 272 source files to /home/hinrichs/projekte/josm/build
[javac]
/home/hinrichs/projekte/josm/src/org/openstreetmap/josm/gui/dialogs/RelationListDialog.java:74:
method does not override a method from its superclass
[javac] @Override public void valueChanged(ListSelectionEvent
e) {
[javac] ^
[javac]
/home/hinrichs/projekte/josm/src/org/openstreetmap/josm/gui/dialogs/RelationEditor.java:297:
method does not override a method from its superclass
[javac] @Override public void valueChanged(ListSelectionEvent
e) {
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
BUILD FAILED
/home/hinrichs/projekte/josm/build.xml:70: Compile failed; see the compiler
error output for details.
Total time: 8 seconds
signature.asc
Description: This is a digitally signed message part.
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another Java version conflict
Andre Hinrichs schrieb:
Hi List,
there is again an error in the sources which only occurs in Java 5 but is
fine
in Java 6. Since the compile server runs on Java 5 it does not build a new
JAR for downloading.
Here is the error message:
$ ant dist
Buildfile: build.xml
init:
[mkdir] Created dir: /home/hinrichs/projekte/josm/build
[mkdir] Created dir: /home/hinrichs/projekte/josm/dist
compile:
[javac] Compiling 272 source files to /home/hinrichs/projekte/josm/build
[javac]
/home/hinrichs/projekte/josm/src/org/openstreetmap/josm/gui/dialogs/RelationListDialog.java:74:
method does not override a method from its superclass
[javac] @Override public void valueChanged(ListSelectionEvent
e) {
[javac] ^
[javac]
/home/hinrichs/projekte/josm/src/org/openstreetmap/josm/gui/dialogs/RelationEditor.java:297:
method does not override a method from its superclass
[javac] @Override public void valueChanged(ListSelectionEvent
e) {
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
My mistake!
I'm a bit unsure how to fix this. Simply remove the @Override statements?
Regards, ULFL
P.S: Hmmm, I don't get those problems with my (latest) JDK version. I
thought that the ant scripts were telling the JAVA compiler to be 1.5
like - so I should see this?!?
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another Java version conflict
On Dienstag, 20. Januar 2009, Ulf Lamping wrote: My mistake! I'm a bit unsure how to fix this. Simply remove the @Override statements? I would say yes, since the annotation is to tell the compile to through errors when there a method is misspelled. Java 5 allows this only for super classes and java 6 also allows this for interfaces. Since getValue is defined in an interface this workes only for Java 6. It compiles fine here if I remove the @Override annotations. Regards, ULFL P.S: Hmmm, I don't get those problems with my (latest) JDK version. I thought that the ant scripts were telling the JAVA compiler to be 1.5 like - so I should see this?!? If you have UNIX you can call java-config -L to get available Java versions. You have to set the Java version with java-config -s n Don't know if this is the same procedure for Windows... Regards Andre signature.asc Description: This is a digitally signed message part. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another Java version conflict
Andre Hinrichs schrieb:
On Dienstag, 20. Januar 2009, Ulf Lamping wrote:
My mistake!
I'm a bit unsure how to fix this. Simply remove the @Override statements?
I would say yes, since the annotation is to tell the compile to through
errors
when there a method is misspelled. Java 5 allows this only for super classes
and java 6 also allows this for interfaces. Since getValue is defined in an
interface this workes only for Java 6.
It compiles fine here if I remove the @Override annotations.
It also compiles fine if I just remove it. I've fixed it in SVN1303.
Funnily I just copied and modified the line from above in
RelationListDialog.java:64
@Override public void mouseClicked(MouseEvent e) {
which looks quite similiar and seem to work with your JDK.
Life is not fair sometimes ;-)
Regards, ULFL
P.S: Hmmm, I don't get those problems with my (latest) JDK version. I
thought that the ant scripts were telling the JAVA compiler to be 1.5
like - so I should see this?!?
If you have UNIX you can call java-config -L to get available Java versions.
You have to set the Java version with java-config -s n
Don't know if this is the same procedure for Windows...
Windows
Although source and target settings for javac in the ant script are set
to 1.5, javac seems to simply ignore them (at least jdk1.6.0_11 on
Windows) :-(
As this problem don't seem to happen very often, please let us know if
that happens again, as I just can't check it here ...
Regards, ULFL
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another Java version conflict
On Dienstag, 20. Januar 2009, Ulf Lamping wrote:
Andre Hinrichs schrieb:
Hi List,
there is again an error in the sources which only occurs in Java 5 but is
fine in Java 6. Since the compile server runs on Java 5 it does not build
a new JAR for downloading.
Here is the error message:
$ ant dist
Buildfile: build.xml
init:
[mkdir] Created dir: /home/hinrichs/projekte/josm/build
[mkdir] Created dir: /home/hinrichs/projekte/josm/dist
compile:
[javac] Compiling 272 source files to
/home/hinrichs/projekte/josm/build
[javac]
/home/hinrichs/projekte/josm/src/org/openstreetmap/josm/gui/dialogs/Relat
ionListDialog.java:74: method does not override a method from its
superclass
[javac] @Override public void
valueChanged(ListSelectionEvent e) {
[javac] ^
[javac]
/home/hinrichs/projekte/josm/src/org/openstreetmap/josm/gui/dialogs/Relat
ionEditor.java:297: method does not override a method from its superclass
[javac] @Override public void
valueChanged(ListSelectionEvent e) {
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
Sorry, my error report was for version 1297 because I went back in the
versions to find what was wrong but in 1298 there was another one introduced.
So two errors are fixed now and one is left:
$ ant dist
Buildfile: build.xml
init:
[mkdir] Created dir: /home/hinrichs/projekte/josm/build
[mkdir] Created dir: /home/hinrichs/projekte/josm/dist
compile:
[javac] Compiling 272 source files to /home/hinrichs/projekte/josm/build
[javac]
/home/hinrichs/projekte/josm/src/org/openstreetmap/josm/gui/dialogs/RelationEditor.java:303:
method does not override a method from its superclass
[javac] @Override public void valueChanged(ListSelectionEvent
e) {
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
BUILD FAILED
/home/hinrichs/projekte/josm/build.xml:70: Compile failed; see the compiler
error output for details.
Total time: 9 seconds
signature.asc
Description: This is a digitally signed message part.
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another Java version conflict
On Dienstag, 20. Januar 2009, Ulf Lamping wrote: As this problem don't seem to happen very often, please let us know if that happens again, as I just can't check it here ... Ok, will do this in the future. Regards Andre signature.asc Description: This is a digitally signed message part. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another Java version conflict
Andre Hinrichs schrieb: Sorry, my error report was for version 1297 because I went back in the versions to find what was wrong but in 1298 there was another one introduced. So two errors are fixed now and one is left: fixed in 1306 Regards, ULFL ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Another Java version conflict
On Tue, 20 Jan 2009, Ulf Lamping wrote: P.S: Hmmm, I don't get those problems with my (latest) JDK version. I thought that the ant scripts were telling the JAVA compiler to be 1.5 like - so I should see this?!? No. This seems to affect the Java code only. Not the parsing, which is a bit strange. Also the String.isEmpty() and other Java 1.6 stuff is not warned even if you have source set to 1.5 also. But there IS a change. For openSUSE 11.1 I get installation errors for software when the 1.5 target is not used (during RPM building). Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
