Addresses #1253.

Awesome, thank you! I have yet to actually test it but my initial thoughts are to split the code into gui and python library, so you would have also python/grass/projpicker/ where you would have the code unrelated to gui. If I understood the code correctly, this PR also includes a standalone version, in that case it should be named g.gui.projpicker to be consistent with other standalone gui parts.

Also, we don't need the tk code here.

Awesome, thank you! I have yet to actually test it but my initial thoughts are to split the code into gui and python library, so you would have also python/grass/projpicker/ where you would have the code unrelated to gui.

Split in 37a1c6f.

If I understood the code correctly, this PR also includes a standalone version, in that case it should be named g.gui.projpicker to be consistent with other standalone gui parts.

That standalone version just happens to be part of projpicker.py, but it's not meant to be run from GRASS. Actually, it's not even a GRASS module. I think I'd better move g.projpicker to g.gui.projpicker?

Also, we don't need the tk code here.

Removed in 37a1c6f.

Very nice! Just wondering if users understand that they can identify suitable CRS from a map when they read Select CRS spatially?
Maybe Select CRS in a map or Select CRS interactively in a map is more clear? Just for your consideration. This is a really userfriendly addition in any case...

Select CRS interactively in a map

Like this! Thanks for the suggestion.

Seems to work well! When I first opened the wizard it took quite a bit of time, I assume because downloading OSM. Would it be possible to download only when you actually select this option? Or better, do it in separate thread.

The help is little overwhelming with a lot of options. Perhaps we could have a toolbar above the map, similarly to r.li.setup wizard. In any case, I think drawing bbox should be default, not polygon. The search shouldn't be case sensitive.

Overall I feel this should be eventually merged with the second option (Search by EPSG), because there is already an overlap in terms of the functionality and it would make sense from user point of view. That's for a different PR though.

When I first opened the wizard it took quite a bit of time

I think this is because of self.ppikpage.DoLayout()?

I think drawing bbox should be default, not polygon.

I think we just need bbox, no point, no polygon at all. Or maybe keep bbox and point only?

The search shouldn't be case sensitive.

Search is already case insensitive.

Overall I feel this should be eventually merged with the second option (Search by EPSG), because there is already an overlap in terms of the functionality and it would make sense from user point of view. That's for a different PR though.

I agreed.

When I first opened the wizard it took quite a bit of time

I think this is because of self.ppikpage.DoLayout()?

I guess. I was trying to look what is causing that but I got quickly confused from all the code. There is a lot of gui code, the help text is repeated there 3 times, is that all used at all? The file names could be more helpful (projpicker_gui/gui.py, gui_common.py, wxwidgets.py? ).

I think drawing bbox should be default, not polygon.

I think we just need bbox, no point, no polygon at all. Or maybe keep bbox and point only?

I agree simplicity may be best, bbox could be enough. I am still thinking about the toolbar like in r.li.setup wizard plus adding a tool to clear polygons:

When I first opened the wizard it took quite a bit of time

I think this is because of self.ppikpage.DoLayout()?

I guess.

I think it is the DoLayout() call that starts running the projpicker even before opening the page.

I'm not sure if that's a good idea or necessary to call Layout() that early. Downloading is done in a separate thread only for zooming at the moment to avoid excessive zoom requests. If this Layout() call is absolutely necessary at the beginning of the Location Wizard, background downloading might be a solution.

I was trying to look what is causing that but I got quickly confused from all the code. There is a lot of gui code, the help text is repeated there 3 times, is that all used at all? The file names could be more helpful (projpicker_gui/gui.py, gui_common.py, wxwidgets.py? ).

Only one copy of the help message is used. We only use the "map_left" layout and these files are still mostly straight copy-paste from the original project. Needs more work. I think I need to turn this PR to a draft to make that clear.

I think drawing bbox should be default, not polygon.

I think we just need bbox, no point, no polygon at all. Or maybe keep bbox and point only?

I agree simplicity may be best, bbox could be enough. I am still thinking about the toolbar like in r.li.setup wizard plus adding a tool to clear polygons:

Agreed on bbox only. About the toolbar idea... I need an artist ;-). Right now

• drag for panning
• scroll for zooming
• ctrl+drag for bbox zooming
• click-move-double click for drawing bbox
• click-move-drag-move-double click for drawing bbox with panning
• right click to cancel drawing
• double right click to clear everything

So.. icons, we would need

• zoom in
• zoom out
• pan
• bbox (no more start drawing -> click and pan -> complete; just single click to complete, which is not implemented)
• clear

And remove the Help tab.

TODO

• Remove ProjPicker-only code (I'll keep enough code for g.projpicker though, which will include the more full-blown wxPython GUI).
• toolbar
• i18nify user-visible messages
• pylint
• black? Other GUI code is not black-formatted yet?

Other GUI code is not black-formatted yet?

Why do you think so? It should be.

Other GUI code is not black-formatted yet?

Why do you think so? It should be.

You're right! It was my code in wizard.py.

ValueError is likely still the best one here. NotImplementedError has a specific meaning when working with abstract classes/methods, at least that's how it is defined:

https://docs.python.org/3/library/exceptions.html#NotImplementedError

I think any builtin errors are defined specifically for Python internally? For example, SyntaxError may not be meant for custom syntax like ProjPicker Query. Maybe, it would be better to define my own custom errors (best practice?), but I just prefer not to do that if I can recycle builtin errors (bad idea?).

Current shortcuts

Pan:               Left drag
Zoom:              Scroll
Zoom to bboxes:    Ctrl + scroll up
Zoom to the world: Ctrl + scroll down
Zoom to a bbox:    Ctrl + left drag
Draw a bbox:       Left click
Cancel drawing:    Right click
Clear:             Double right click

No more polygons and points.

@wenzeslaus, @petrasovaa - I have spoken with @HuidaeCho about plans to take over this PR. I am unable to commit directly to the PR at the moment (tried standard git workflow of adding his remote branch, making local branch and then committing to remote branch head), and wanted to inquire what the best approach to start working directly off the PR would be.

@ocsmit I don't think there is a easy way of getting access to someones branch except 1) getting access to their repo and 2) when you are a maintainer of the project the PR was submitted to. Conclusion: To overtake the work on this, you need to get this branch locally, push it to your fork and open a new PR.

I would say, no harm done here opening a new PR. There is plenty of comments here, but they seem to be mostly resolved (please check), so opening a new PR will clear the old stuff. Restating and updating the goals and methods in the PR description might be helpful too.