Handling imagery offsets when reprojecting?

[RicoElectrico]

If a layer is reprojected, the offset dialog specifies it in the main projection units instead of the layer's projection unit. It seems to confuse JOSM when you switch projections.
I can confirm it messes up things when you

1. Use EPSG:2180
2. Specify offset for Bing
3. Switch to EPSG:8357
4. See that offset is quite different.

[RicoElectrico]

Oops, I meant EPSG:3857
Also, even though offset CRS is stored when using bookmarks, it's still messed up when loaded with a different CRS.

[bastiK]

Thanks for the report, I can reproduce the problem. If you remove and re-add the layer, you will notice, that only bookmarks matching the current projection will be available. So it is a bit of an oversight, that the current offset is retained when switching projections.

But instead of resetting the offset to zero, it would be more useful, to convert offsets dynamically from one projection to another. This can only be done with respect to a fixed reference point. Luckily, we already save the reference point for offset bookmarks (it seems, they aren't used so far).

In this system, the projection to store the bookmark in, gets kind of arbitrary, it might as well be EPSG:4326 (lat/lon). But it may still be interesting to note which projection was used when creating the bookmark.

[bastiK]

In 12084/josm:

offset bookmarks: migrate preferences from lists to key=value maps (+add getters & setters) (see #14734)

[bastiK]

In 12085/josm:

fix compile (see #14734)

[bastiK]

In 12093/josm:

fixed #14734 - Handling imagery offsets when reprojecting

[bastiK]

In 12094/josm:

update test (see #14734)

[Don-vip]

Can you please add @since tags for new public APIs? It helps to maintain plugins.

[Don-vip]

Also at the same time there are checkstyle warnings. Have you tried the ​Netbeans plugin?

[bastiK]

Replying to Don-vip:

Can you please add @since tags for new public APIs? It helps to maintain plugins.

Is it possible to write @since $rev or something and have it fill in the revision automatically?

Replying to Don-vip:

Also at the same time there are checkstyle warnings. Have you tried the ​Netbeans plugin?

No, I'll check it out.

[Don-vip]

Replying to bastiK:

Replying to Don-vip:

Can you please add @since tags for new public APIs? It helps to maintain plugins.

Is it possible to write @since $rev or something and have it fill in the revision automatically?

It would be great but I don't know if it's possible :(

[Don-vip]

In 12117/josm:

see #14734 - fix PMD warning

[Don-vip]

In 12118/josm:

see #14734 - fix checkstyle warnings

[michael2402]

Replying to Don-vip:

Replying to bastiK:

Replying to Don-vip:

Can you please add @since tags for new public APIs? It helps to maintain plugins.

Is it possible to write @since $rev or something and have it fill in the revision automatically?

It would be great but I don't know if it's possible :(

Use @since xxx

Then run this before you commit:

svn up && REV=$(svn info -r 'HEAD' | grep Revision: | awk -F' ' '{print $2}') && find ./ -type f -exec sed -i -e "s/@since xxx/@since $(($REV + 1))/g" {} \;

(it will change all files and not check which ones you actually commit)

[bastiK]

In 12120/josm:

new script to insert revision number for Javadoc @since xxx (see #14734)

[bastiK]

Replying to michael2402:

Replying to Don-vip:

It would be great but I don't know if it's possible :(

Use @since xxx

Then run this before you commit:

svn up && REV=$(svn info -r 'HEAD' | grep Revision: | awk -F' ' '{print $2}') && find ./ -type f -exec sed -i -e "s/@since xxx/@since $(($REV + 1))/g" {} \;

(it will change all files and not check which ones you actually commit)

I've added a script that does essentially this. Now I just have to remember to run it.

[stoecker]

I've added a script that does essentially this. Now I just have to remember to run it.

Nice. I once tried to do this on the server, but SVN does not allow hooks, which change the submitted content (there is no feedback possibility to the client, so states could be inconsistent and thus it is forbidden).

[Don-vip]

Nice, but why in Python? We already have several script languages (Groovy, Perl).

I like Python, but we shouldn't add it to JOSM just for this feature. I'd prefer something (Ant task ?) which doesn't require to install another framework.

[bastiK]

To be honest, I didn't think much about it. Python runtime should be pretty common and it's not like it is mandatory to use this script. Feel free to port to Groovy/Java/ant, though. ;)

[michael2402]

I think python is more common on Linux than Groovy ;-).

As long as it is just a script that can be used if it matches the personal workflow, I don't care about the language. I'd rather not have those version control features in ant.