Modify

Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#14734 closed defect (fixed)

Handling imagery offsets when reprojecting?

Reported by: RicoElectrico Owned by: team
Priority: normal Milestone: 17.05
Component: Core imagery Version:
Keywords: Cc: michael2402

Description

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.

Attachments (0)

Change History (20)

comment:1 Changed 13 months ago by 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.

comment:2 Changed 13 months ago by bastiK

Cc: michael2402 added

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.

comment:3 Changed 13 months ago by bastiK

In 12084/josm:

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

comment:4 Changed 13 months ago by bastiK

In 12085/josm:

fix compile (see #14734)

comment:5 Changed 13 months ago by bastiK

Resolution: fixed
Status: newclosed

In 12093/josm:

fixed #14734 - Handling imagery offsets when reprojecting

comment:6 Changed 13 months ago by bastiK

In 12094/josm:

update test (see #14734)

comment:7 Changed 13 months ago by Don-vip

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

comment:8 Changed 13 months ago by Don-vip

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

comment:9 Changed 13 months ago by Don-vip

Milestone: 17.05

comment:10 in reply to:  7 ; Changed 13 months ago by 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.

comment:11 in reply to:  10 ; Changed 13 months ago by 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 :(

comment:12 Changed 13 months ago by Don-vip

In 12117/josm:

see #14734 - fix PMD warning

comment:13 Changed 13 months ago by Don-vip

In 12118/josm:

see #14734 - fix checkstyle warnings

comment:14 in reply to:  11 ; Changed 13 months ago by 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)

comment:15 Changed 13 months ago by bastiK

In 12120/josm:

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

comment:16 in reply to:  14 ; Changed 13 months ago by 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.

comment:17 in reply to:  16 Changed 13 months ago by 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).

comment:18 Changed 13 months ago by 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.

comment:19 Changed 13 months ago by 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. ;)

comment:20 Changed 13 months ago by 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.