Pattern for the name of attachment to geocaches

Willy shared this question 3 years ago
Answered

Hello to all!


I am not new to Locus Pro but i am new to this support forum.

Refering to this thread i have the following question:


Very often it is useful to make pictures during geocaching. Recently i found the function of "attachments". That is quite useful but it would be absolutely perfect if the pattern would include the GC-Code. Now the patter is "P_gc-name_timestamp". It would be great if the filename starts with the gc-code like "GC12345" as the code of a geocache is unique and very important to find the matching picture later on. So for example a filename of an attachment to a geocache should be like this: "GC4WFQN_Old_Erlaa_20170428_125250.jpg"


I think the perfect way would be if the user can set userdefinded pattern. But if not, maybe Locus can use different patterns for adding attachments to a geocache. This would be very helpful because for now i still need to rename each picture by myself after archiving it to the PC because without the code its almost impossible to find it after some time.


Apologies if my english is not well.


Regards, Willy

Comments (6)

photo
1

Good day Willy,

thank you for your question/idea , interesting.


To be true, I do not think that extending Locus Map to allow some custom pattern is necessary, we still may try to find some universal solution.


You talk about GC code. What about completely remove a name of cache and adding there only a cache code? So in your sample, it should look like this: 'GC4WFQN_20170428_125250.jpg'?


Or is name itself useful as well? Even now, name is quite long so I'm just looking if there isn't option to make it shorter.

photo
1

Hi Menion,


for me this would be the perfect solution.


c.s.g.

photo
2

Hello Menion,

Actually, the GC-Code is a must in the file name to find photos refering to a cache later on. The name of the cache is not very necessary, but very helpful. Because sometimes if you want to look for a photo you don't remember the code, but you remember the name of the cache. But you are right, sometimes the name can be quite long.

But for me, the timestamp is not really necessary. And the timestamp is also included in the EXIF-Data. So if someone want the timestamp to be in the filename it's easy to add it with other tools like EXIF-Tool or other tools for mass file renaming (Total Commander, KRename and so on).

So for me it would be also ok if the filename looks like that:

"GC4WFQN_Old_Erlaa.jpg"

But in this case it would be useful to add a counter in case that there are more than one photos for the same geocache:

"GC4WFQN_Old_Erlaa_#1.jpg"

"GC4WFQN_Old_Erlaa_#2.jpg"

The maximum length of the name of a geocache is 50 characters. A gc-code is maximum of 7 characters. So with the underline the maximum possible length of a filename without the timestamp can be 58 characters. Together with the timestamp (and another underline) it would be 74.

Are there any restrictions due to the maximum length of a filename in the filesystem of Android?

I calculated the average length of a geocache name out of a database of 15959 geocaches and it is 20,3 characters.

BUT: The more important thing would be to exclude invalid characters like ~ " # % & * : < > ? / \ { | } from the filename. characters like that can definitely appear in geocache names. It's ok to replace them with blank or just ignore them.

Finally:


  • The GC-Code is absolutely necessary
  • The name is very useful
  • The timestamp is not necessary for me as it is also in the EXIF-Data and easily addable by other tool.

Regards, Willy

photo
1

I find the length of the file name does not matter. Important is the important information at the beginning. So you could make the time stamp back.


GC-Code_Name_Time

photo
1

Hi guys, thanks for a feedback, appreciate it! Mainly Willy for interesting stats about name length, funny :).


Oki, I believe all will be satisfied. Since next version, naming for caches will be :


  1. {GCCode}_{name, max 15 characters}_time

For a common points it remains as now (except length of name), so:


  1. P_{name, max 15 characters}_time

photo
1

V 3.23.2

"take photo" inside geocache attachement, naming work ;-) but not with "select photo" from folder

photo
1

Hello balloni,

in case of "select photo", it should just use already existing name of selected photo. Or you wants to rename selected photo?

photo
1

> Or you wants to rename selected photo?

in this case, yes

on geocaching tour i take some photos and later i decide to attache some of these direct to a cache, so these photos should be renamed.

photo
1

Hmm I cannot agree. Locus cannot know if you are not using any different application that use some, for you, more logical naming system.

I'm quite sure that if Locus Map will rename attached files, some people will want to disable it.

photo
1

if i take a photo inside geocache attachement currently it´s stored twice

- locus/data/media/photo/GC12345_name_date_124110.jpg

and

-DCIM/camera/IMG_date_124116220.jpg

so i can imagine, in case user add photos (from folder) to geocache attachement, these photos are copied to locus/data/media/photo and renamed only in this folder similar a taken one.

So it will be identically while export, independent they are taken or selected from folder

photo
1

It's stored twice?? Then it's definitely issue of camera app, because photo should be only stored into destination where Locus requests, so only once into Locus/data/media directory.


If something change here, I can imagine simple question after you pick an file "Do you want to copy file into Locus Map directory?". Anyway I cannot say how much useful it should be to duplicate content in your device.

photo
photo
1

Thank you very much Menion for the fast implementation of the pattern of filenames! It works fine.

However the 15 characters seem to be a bit too less. I tried out the new renaming schema for a time and often a few characters were cut from the name. I guess you have your reason for the limitation but why it's 15? I guess 30 would be a good choice. However, thanks for the solution that is implemented now.


Regards, Willy