Feature: Android: Generate scribble layer

[mlerjen]

The generation and placement of a geo-referenced scribble layer for the android version is pretty much complicated at the moment. Especially for beginners. I would therefore like to propose you add a "add scribble layer" functionality to the android version. The function could be triggered in the template manager under "+">"add scribble layer" giving two options: resolution (? necessary?) and extent (entire map/actual window). The result would be a geo-referenced transparent .png with the chosen resolution and with a 3px(?) red border added as layer to the template stack.

[dg0yt]

Basically this was on the list of ideas when Thomas published the Android prototype. Good to have it as an issue now.

(To be honest, I always used freehand drawing with symbols instead. But the scribble feature avoids changing the original file which mitigates our OCD limitations.)

[ollesmaps]

I agree, this would be a welcomed feature. It could perhaps be also possible to make a new .omap file with the android app. I can imagine situations I am somewhere out and there is a sudden need of mapping. (For example a course planner encounters a new clearing).

[ollesmaps]

Resolution is necessary, how many meters in pixel. The rectangle could be defined by two points - so a rectangle not necessarily to window size can come up.

There are online image generators, as https://dummyimage.com/ So generating just .pgw might be an option.

[dg0yt]

There are online image generators, as https://dummyimage.com/

Well, generating the blank image is the least difficult part.

Especially on Android, there is hardly an alternative to doing it in Mapper. You may be offline, and Android security design could make it hard to put a download into a writable folder belonging to the Mapper app.

[mlerjen]

A general comment (android, fieldwork): The size of the scribble layer has a crucial effect on the time span blocked by the autosave. While it is around 5 seconds for a 500KB raises to a painful 25-30 seconds for a 4.5MB. It is therefore advisable to split the scribble layer over an entire map project into multiple parts resp. work with multiple scribble layers. This also lowers other risks linked with the scribble layer as the container of your fieldwork/value. I suffered three losses so far, all related to the file size of a single whole-project scribble layer (2x incomplete cloud uploads, 1x incomplete saving before low battery shutdown).

[ollesmaps]

Does the autosave time relate also to RAM, frequency? I keep the scribble layer in maximum size something around 4000*4000 pixels. But that is the limit afterwards it takes too loong to save. What is your meter : pixel ratio? Mine is usually 0,4 - 0,6 meters : 1 pixel.

[ollesmaps]

The perfect feature would be to autosave when not drawing - when moving from place to place for example. But how to detect it? Just brainstorming here:

• accelerometer?
• when I move from one place to another I usually switch off screen, at this moment autosave would be good
• no action (30 secs?) automatically autosave, also mentioned here #982

[mlerjen]

I switched from 0.5m (below) to 1m (above) this mostly due to the type of content I use to scribble (contours and areas). There I like to "fill" the areas.

[mlerjen]

Working with larger scribble layers up to 5 MB I used to press "save" before moving to the next place (this I assume restarts the timer for the auto save). For now the issue is worked around with a set of smaller scribble scraps. Of course, any sort of non- or less-interrupting saving solution would be preferable.

[yevhenmazur]

But how to detect it? Just brainstorming here:

Mapper tracks your GPS position. Why not use this feature to detect are you moving or not?

[lpechacek]

Of course, any sort of non- or less-interrupting saving solution would be preferable.

File saving can happen in a separate execution thread (read in background). It might be difficult to implement in a way that data do not get lost during saving and I don't know dg0yt's attitude towards multi-threaded programming. Anyway, that are programmer's headaches. The result of background file saving is transparent to the user.

[dg0yt]

Of course, any sort of non- or less-interrupting saving solution would be preferable.

File saving can happen in a separate execution thread (read in background). It might be difficult to implement in a way that data do not get lost during saving and I don't know dg0yt's attitude towards multi-threaded programming. Anyway, that are programmer's headaches. The result of background file saving is transparent to the user.

While multithreaded saving might be hard in general, saving modified templates (scribble image, GPX track) could perhaps be moved to another thread more easily.

However, first there should be investigation on the actual bottleneck : simply IO, or compressing the image. Anyway, smaller images (tiles) will be more efficient: You don't need to process what you didn't change.

[ollesmaps]

I would suggest then:

• when there is a feature to generate scribble layer, to automatically devide scribble layer into optimal tiles
• keep these tiles of one scribble layer as one template, so handling is easier

[dg0yt]

As long as we don't have tiles, a button to add a reasonably sized image in a reasonable resolution at the current location would be good start.

[dg0yt]

I'm about to add this feature as follows:

• no GUI options, just "Add template..."
• resolution: 10 pixel per mm, e.g. 1 pixel per m at 1:10000
• image size app. 1000x1000 pixels (note: you can add more templates any time as needed)
• image center app. center of current view, but:
• image top left corner somewhat "aligned" to (multiples of) projected coordinates
• red border (can be drawn over)
• red label in top left corner given the corner's projected coordinates
• file named like "map-file-name @ top-left-coords.png"

Question: Where to insert this template (initially): a) just above the map layer, or b) just below the map layer?

[ollesmaps]

I have it just bellow the map layer.

[lpechacek]

(opinion poll in progress :) ) My one is above map player.

Regarding resolution, I settled on 0.03m/px. 1m/px was too coarse. Otherwise the proposal looks good to me.

[mlerjen]

The same for me. Just below the map layer. fig.1. The active scribble layer just below the map plus the layers shall have simple & easy to identify names.

A comment regarding the files name: Neither map-file-name nor top-left-coords seem helpful to identify a scribble layer inside the template dialog. Personally I would prefer a simpler naming a like draft_XX where XX is an ascending numbering and the file being saved in the same directory as the .omap file.

[dg0yt]

I switched from 0.5m (below) to 1m (above) this mostly due to the type of content I use to scribble (contours and areas). There I like to "fill" the areas.

This sounds like would like to use a different pen size for filling areas at a higher image resolution.

[dg0yt]

The "Add new template.." option will appear in the dialog where you select the template for scribbling.

For now, I adopt the following modications:

• The template is added below the map layer.
• The file name is shortened to "Draft @ top-left-coords".

I will trigger new master builds in a few minutes, so you can test on Windows and Linux and give more feedback:

• Shall the template be added above or below the map?
• Shall the image resolution be increased?
• Shall the image size be increased?
• Shall the file name be created in a different way, or do you even want to enter a name?

[mlerjen]

Thanks a lot! -> I still think it would be more intuitive to have the functionality inside the template manager -> I could imagine to optionally deduct the extent of the new scribble layer from the extent of a selected object. That way one could draw a rectangle over the area needed exactly.

[ollesmaps]

I would prefare better resolution. 1px 1m is too little for me. At least 0,8m per 1px would be good.

[dg0yt]

1px 1m is too little for me. At least 0,8m per 1px would be good.

I want to avoid odd values. Now we have 1 px per 0.1 mm (= 1 m @ 1:10.000). Next step is 1 px per 0,05 mm (= 0.5 m @ 1:10000). We could try to do it for the same mapped area, i.e. 4 times the number of pixels per image, if speed is not an issue for the current resolution.

[mlerjen]

Nowadays I work a lot with this feature... I just create a new template as soon I reach the edge of the old one. The "saving time" issue is gone. What I wonder now, is where the Geo-reference of these layers is defined as there is no .pgw. Is it in the project, the .png or just the title? (wow can I rename the file? Can I remove the template from the project without losing Geo-reference?)

[dg0yt]

There is no external georeferencing yet. I assume it would be easy to add world files, and it is somewhat anticipated by the given aligment of the top-left corner.

However I wanted to discuss one more twist for that: Generate the images rotated to the grid coordinates. Most of the time, the images don't match the screen resolution anyway. With the change to grid rotation, the program could easily generate images which are aligned in a perfect grid (with some overlapping). The next step is to do hide the whole complexity of creating/switching these images. This could result a nice mode for fieldwork on unmodifed OCD files.

[ollesmaps]

@dg0yt This twist would be welcomed :)

[ollesmaps]

Is there a way to open the draft scrible layer in exact desired location?

[dg0yt]

Is there a way to open the draft scrible layer in exact desired location?

No, it is really quite cumbersome at the moment.

[ollesmaps]

@dg0yt I would say it is "in-the-middleish" of screen. If it can be exactly in the middle of screen that would be perfect. Shall I make a separate issue?

[dg0yt]

@ollesmaps IIUC now, by "open" you mean "create", not "select"? The corner of a new "layer" is aligned to ...000 grid coordinates, relative to the center of the screen, i.e. it is intentionally not exactly the middle.

These "patches" should be replaced with a convenient, single tiled layer anyway.

[ollesmaps]

I see. So if I switch on grid, I can predict the placement of the created scribble layer. I will try.

FIY For my latest sprint map (1,8 km2) I switched from having one big white png to generating scribble layers on the go. It was definitely faster regarding the saving time. However navigating in the sribble layers is a mess (and time consuming). I generated 25 of them!

I will see how it works with the grid info.

[mlerjen]

@ollesmaps: I am thinking about a workflow where I work with two scribble layers over the entire map area.

One is for the mapping of today "scribble_today". The other contains all the merged scribble from earlier days "scribble_all". That way I would only have two distinguishable scribble layers and the one covered in the auto-save rotation never gets to heavy...

(In the evening you export the combo of scribble_today and scribble_all as the new scribble_all; then you make scribble_empty the new scribble_today.)

[ollesmaps]

@dg0yt I tried the grid (50m) placement. See attached jpeg. Purple rectangle - desired place. Red rectangle - reality. Any ideas how to place it exactly where I like? Would a function Zoom on selected object help?

[dg0yt]

The corner of a new "layer" is aligned to ...000 grid coordinates, relative to the center of the screen, i.e. it is intentionally not exactly the middle.

I tried the grid (50m) placement. See attached jpeg.

I'm sorry. There is a misunderstanding. When I said "grid", I meant to refer to the projected coordinate system, not the displayed grid. Your screenshot illustrates this behaviour quite nicely.

Any ideas how to place it exactly where I like?

You can do this on the desktop. Adding tiles on the fly was meant as an interim solution, for ad-hoc field work, or when you forgot to do it in advance.

[ollesmaps]

The pictured grid is set as projected coordinate system. I am aware of this behaviour.

[dg0yt]

Sure, but I also meant '...000' coordinates. The screenshot doesn't show 1000 m grid width?

[dg0yt]

Sure, but I also meant '...000' coordinates

I admit this isn't entirely correct. I would have to lookup the exact implementation.

[dg0yt]

The generated images are 100 mm x 100 mm at 10 px per mm. So the coordinates are rounded to multiples of a 'base' which is dependent on scale. For 1:10000, the base is 100 m.

https://github.com/OpenOrienteering/mapper/blob/271fcf7f042fd3f14cec8f57b8c69e0f63af4839/src/templates/template_tool_paint.cpp#L72-L105

[ollesmaps]

Oh I see! I derived the 50m grid from a sprint map, where I noticed some templates were generated with 50 at the end. Obviously this was caused by the larger scale. Will give it another try. Thank you!