Geotagging For Financial Intelligence

#1

I’ve been doing this and it’s been a real eye opener!

Using OpenStreetMap, I extract the position of a supermarket from the URL: OpenStreetMap = 35.673204/139.736347

Google does it differently, and uses a “,” instead of a “/”: Google マップ

I put that in my title. For consistency, I change it over to 6-digit hex-like sets, getting rid of the decimals and adding "0"s and hyphens:
35.673204,139.736347 → 35673204,139736347 → --0035673204--0139736347 → --003567-3204--013973-6347 → --003567-320400--013973-634700 → --003567-320000--013973-630000

Notice I simplified the position in the last step.

All of this can be done in the address bar next to the URL; a sort of mini workspace editor (I use the TW search bar in this way).

To change it back, I do this: --003567-320000--013973-630000 → 003567-320000/013973-630000
→ 0035.67320000/0139.73630000

I’ll bet you’ve tuned out at this point.

But that’s it. I don’t need to get rid of the extra zeros. But if I did: 35.6732/139.7363

I could be making tiddlers and set a field to the geotag. But I prefer simple: geotag the title: --003567-320000--013973-630000

--000166-000100--1-Package--3-Fruit--FNIntelligence--Costs--Apples (the 000100 represents “1” as the last two zeros are the decimals). For quantity per gram or litre, the same applies: --000054-000100--2L--Bottle--FNIntelligence--Costs--WheatTea. For packages: --000199-000100--1-Package-2-Slices--FNIntelligence--Costs--Pizza.

I geotag my tiddler titles like this: --003567-320000--013973-630000--000199-000100--1-Package-2-Slices--FNIntelligence--Costs--Pizza (this means I paid 199 yen per slice).

But wait, there’s more! I have to give it a time stamp: --202509-252205--202509-252205--003567-320000--013973-630000--000199-000100--1-Package-2-Slices--FNIntelligence--Costs--Pizza

The FNIntelligence is a tag.

I forgot to mention I use double hyphens to make it easier to look through the long titles.

Finally, I place an address to the beginning of the title: PBof25-FNin09--202509-252205--202509-252205--003567-320000--013973-630000--000199-000100--1-Package-2-Slices--FNIntelligence--Costs--Pizza

Translated: PUBLIC/offices/2025 -FINANCES/intelligence/09(September). Time stamps are repeated twice vor various purposes. For FROM/TO or for updates, etc…

tags are extracted from the title. I simply paste them into a field value for “tags”: --202509-252205--202509-252205--003567-320000--013973-630000--000199-000100--1-Package-2-Slices--FNIntelligence--Costs--Pizza and then space them out accordingly (as well as get rid of some details): PBof25-FNin09 202509--202509 003567--013973 000199-000100--1-Package-2-Slices FNIntelligence Costs--Pizza

Then I do what nobody here suggests you do: I give them my own tag prefixes: ./PBof25/FNin09 [:202509--202509 [;003567--013973 [$000199-000100--1-Package-2-Slices [#FNIntelligence [?Costs--Pizza

Using the tag manager or the advanced search, I’m able to find things easily.

So, now I’ll tell you how we might use geotagging:

  • To break down items we’ve bought from a receipt. To spot changes over the course of years, or in recent times: months or even weeks.

  • To select some important items from a flyer.

  • Compare prices for similar items at different stores and locations and across different regions. You could ask a friend, who lives abroad what they’re paying for something.

  • Help map out my shopping route for the day: apples at Supermarket A, pork at Supermarket B.

  • Track trends for certain categories of items. Dairy, proteins, local items, dry goods, etc…

I use the clone button so I don’t need to type up the same geotag or time stamps every time I create a new tiddler.

Develop your own way. But I hope I’ve given you some ideas. I welcome your comments, criticisms and ideas. Thank you for reading.

#2

Oh, need to add: use “9” for negation:
OpenStreetMap

-13.075212/-76.373571 → --901307-520000–907637-350000

#3

I’m afraid I’m not following this at all. While I’m slightly curious about the details (how, for instance, does

PBof25-FNin09--202509-252205--202509-252205--003567-320000--013973-630000--000199-000100--1-Package-2-Slices--FNIntelligence--Costs--Pizza

translate into

PUBLIC/offices/2025 -FINANCES/intelligence/09(September)

?), I mostly simply don’t understand why you are doing this. It seems to me that you’re trying to pack all sorts of unrelated information, which I would expect to be in different fields, into the title. What is the advantage of that?

#4

TLDR; but I think I get your idea, geotaged purchase transactions. Part of a financial life blog? Good idea. Sometimes it not the cost I am after just the source of the products I prefer that you cant get everywhere.

A couple of comments,

  • Put the info in seperate fields, dont make compound values you then have to parse when they can sit the in a standard tiddler field.
  • Never use compopunt or only machine readable titles, leave titles for readable descriptions and increment if Needed.
  • Have you looked at what3words?, intergrating that with tiddlywiki is a smart move. You dont need to be so precise, yet still potentialy suggest where the front door is, or an approximate location in store. W3W locations can be set on top of a satelight image so can be used with variations in GPS values, common in big cities. Such locations can be shared with three words.
    • For example this is the last place I found my prefered toothpicks, ///forces.deflection.ladder which is where the actual door is
#5

Fair enough. And thank you.

For the moment, please disregard the title naming that I am using here. But in principal, my titles include a prefix of the Owner/Addressee and where the tiddler or file belongs. A two letter code you could use for yourself might me ST? or SA? or SS? It’s up to you, of course. For me, it’s AF. My wife: IK. My wife AND me: IA (ladies first).

I believe the advantage of having “values” embedded into titles. That way I don’t need to open the tiddlers or query the fields. This approach may not be favoured (evidently) by those accustomed to coding.

Simply put, when lists are created, the titles have the same “values” listed in order.

#6

A good word for What3Words:
What3Words is an impressive tool. Your toothpick example blew me away. Easy to retain that kind of address than the standard coordinate systems out there. Not only for finding things, but also it can become a To Do or a reminder. A farmer might use it to have a list of specific parts of a field to focus on for a particular week.

Use:
So why not use What3Words to geotag in tiddler titles?

As per your example, this is what I might do:
2509-26–forces.deflection.ladder–350–Toothpicks

Initially, this would be the title of the tiddler so I could record the information quickly. Then I would take the parts and place them into their respective fields and values:

w3w: ///forces.deflection.ladder
cost: $3.50
brand: Between The Gums
stores: Fuji, Wallgreens

… and leave the title simple:
2509-26–Toothpicks

Simple tiddler title. Unlikely to find naming conflict there.

1 Like
#7

Yes, much better, But personaly I still would not use compound titles because you will often have to parse them. I have argued this elsewhere in talk.tiddlywiki.

For example years ago I modified the new Journal and new Journal here to set a field journal-date with the UTC tiddlywiki time stamp. I dont care what the tiddler is titled and I never have to parse the title, I just use the journal-title field. This allows me to compare, use the days operator and much more, ie use date handling.

In the toothpicks example I may call the tiddler “Best toothpicks”, and If I found another the default deduped title “Best toothpicks 1”, but at a whim I may call them “Best toothpicks Randwick” and “Best toothpicks Sydney” because there is nothing in the title I need to maintain, just whatever I want to be meaningful.

I hope one day to have a wiki on my phone, perhaps tiddlyhost, that allows me to select a what 3 words location and create a tiddler with its 3 word address in a field and my name for the location as the title. I suppose the three words if not supplied. But I would perhaps call the tiddler “Back entrance to shady nightcub” :nerd_face:

  • Post Script: A key value of W3W is being able to select the location from the satlite image. Kind of a last 20 meter selection escaping the whims of satelites in city canyons.
#8

Counterpoint: it’s a proprietary non-discoverable system and if you’re entering W3W addresses manually, a simple typo can get you anywhere from the wrong side of town, to the wrong side of the planet. A conventional address has a logical structure meaning the impact of typos are inherently restricted, and memorability is increased.

Back on topic - I strongly concur with “put your data in fields”. The titles you have are little better than random unique strings to the casual observer, and to get anything of value to the rest of TW, you’ll need code to extract that. May as well code around fields.

2 Likes
#9

There are free api’s and links, you can store the geolocation and convert it later, you can browse to or open w3w in its app, open it into google maps etc… you can even embed a map with the w3w location displayed in your tiddlywiki. I would personaly only programaticaly capture the w3w word (rather than type). They are designed for circumstances like telling someone over the phone, by design common misspellings or similar word sets put you on the other side of the world. So If I said meet me at this cafe in Randwick and you saw it was on Mount Kilimanjaro then hopefuly you would ask before booking a ticket.

  • I also considerted mapping a block of 3 words to a local 2 word map, for security and venues.

Edited: Having three words in your hands is like having a GPS co-ordinate. Sure you may need w3w to find it, but you can also use the GPS location.

#10

But you know what I can do? I can search the regular (non-advanced) searchbar in the sidebar and find all the sashimi I bought around this location in August of last year: --0035 --0139 --202408 and see how much I paid.

Click on one of them, then drag it’s tag with the relevant information: [?Costs–Sashimi or [;003567–013973 into the side bar.

#11

Free as in beer, not free as in speech. As the saying goes.

Intention of design does not equate to quality result of design.

analysis by Tierney shows that in the London area, around 1 in 24 addresses will be confusable with another London address

In September 2022, the Department for Culture, Media and Sport used What3words to direct mourners to the end of the queue to view the Queen lying in state in London. Of the first five codes published, four led to the wrong place

Those two things appear mutually exclusive to me.

GPS is awkward for casual use, and I get that that’s the problem W3W tries to solve. I just think the problems it introduces means the end result is at best only slightly better, and at worst, considerably worse.

1 Like
#12

yeah, I see the benefit. I’ve been guilty of putting data in titles for search/readability shortcut needs in the past too. If the same data is in fields, then there isn’t an issue - you get the best of both. I had the impression the data is only in the title though?

#13

They are not. But you need to ask how do you use them?

I have seen a number of complaints and not seen any firm evidence against it.

How do you give a fixed address for the end of a Queue?

#14

“Only use programatically” = computer-to-computer

“designed for circumstances like telling someone over the phone” = person-to-person

How is that not mutually exclusive?

Can you try that question again. I dont know what you’re asking.

Presumably that’s why five different addresses were given, as it moved over time far enough from the previous given address, that it was felt worth giving a new endpoint address.

What do you call evidence? Wikipedia lists a number of notable uses both success and failures, as well as an analysis which concluded

If W3W, or any addressing system, is to become critical infrastructure, relied upon by emergency services and other key agencies, then claims for ease of use and reliability should be thoroughly examined and empirically compared to alternatives, from standard street addresses to post codes to newer systems, like PlusCodes.

and

This work has tested some of the claims that W3W makes about their algorithm. These claims are not borne out under scrutiny which suggests that W3W should not be adopted as critical infrastructure without a thorough evaluation against a number of competing alternatives.

– A critical analysis of the What3Words geocoding algorithm - PMC

#15

Absolutely

I have more mixed feelings about this. The title field is first and foremost a primary identifier. There are times when that can also usefully be descriptive text. But often for data-heavy wikis, that makes little sense. But you can nearly always use the caption field for that.

I’d be very concerned about the proprietary nature of w3w. If you’re using it to store both coordinates and three-word addresses, read carefully the restrictions in Section 6.3 of their API license agreement.

#16

To everyone, myself included: Let’s concentrate on a slightly more cordial tone?

I appreciate the suggestion of W3W and I see its merits. I’ve used it a few times and I love it.

AlfieA

#17

I wonder, though, if the title itself is not considered a “field”. And if so, can it not be searched, parsed and listed as such? Can it not carry several data? Especially when the data is in order and separated with markers?
If the title were a date and time:
202509-291026
If the title contained data:
Weight-8900
The last two zeros would be removed. Or considered decimals.

Here’s a list filter I use for my “ToDos”:
<<list-links filter:"!is[system]search:title[2025]search:title[SCTD]search:title[TKPR00]!search:text[Completed]sort[title]]">>
SCTD = SChedules/ToDo. TKPR = TasKs/PRiority 00 = Priority 0 (Must Do / Not Optional)

#18

Yes, the title is a field, as is the main content (the “text” field). But the convention is is that when we’re talking about “fields”, we’re not talking about those two (or “type” field usually, since that is also shown as special and default in the TW edit UI)

Yes, but the general concern we’re expressing about putting all that data into the title, is not really the “into the title” part, but “all that data” part. Our concern would be the same if you were proposing a sensible title summary, and then ALL other data into a field called data (or whatever)

In the traditional unix world there is a philosophy that each program should “only do one thing, and do it well”. By extension, I think a TW philosophy would be “each field should hold one thing, and be easy to (programatically) use”.

By putting multiple bits of data into a single field, no matter how well organised internally, it’s no longer holding one thing, and using any one bit of that data for anything beyond a basic search, is not going to be easy.

In your above example, I’d have the “SCTD” as a tag, and the “TKPRxx” as either a tag (one tag for each priority value) or a field (TKPR as the field name, and the priority number as the field value).

#19

Thank you, Nemo-san. Point taken. Along with the philosophy of a tidder; that it be small and serve one purpose.

Many a tiddler ago, I was putting too much into the text field. And some time after that, I was placing the data into separate fields. Currently, I simply give the text field commas and make the tiddler a text/csv.

But one is torn in this paradox: a tiddler should serve one purpose. And yet its fields include further data? I mean: wouldn’t it be better that have the fields be separate tiddlers themselves?

Don’t get me wrong. I love the fields. And I use them. Namely, I include a “caption” field. And I type up a “tags” field to avoid having to click on the fields’ drop-down and “add”.

My titles have the caption and the tags and sometimes the data.

I understand where you’re coming from, though. From a coding perspective. But from this user’s perspective, it can become tedious. For example:

tiddler title: 2025-09-29 No Lesson With Yamamoto-san. Says everything.

In the fields-friendly version:

title: 2025-09-29 Lesson 
student: Yamamoto-san
lesson-status: no
lesson-date: 2025-09-29
location: school
tags: lesson Yamamoto-san no-lessons 2025-09 school

Why not: 2025-09-29 No Lesson With Yamamoto-san? Easy to search. No “filters” neccessary.

#20

sometimes, yes.

It boils down to what the data is and what makes sense programatically.

For instance, if I was storing an addressbook of people, I’d have a tid as a person, but then facts about their life be fields. eg

title: Douglas Adams
birthdate: 11th March 1952
birthplace: Cambridge, UK
deathdate: 11th May 2001
deathplace: Santa Barbara, California, USA
tags: author famous deceased english [[Monty Python]]

Sure I could overload those fields:

title: Douglas_Adams--11-Mar-1952--Cambridge-UK--11-May-2001--Santa-Barbara-California-USA

…but it would make extraction of things like “show me everyone who was born in 1952” difficult.

And having a “deceased” tag is arguably redundant since it tells me nothing that the existence of a deathdate tag doesn’t do, but makes for convenience - at least, for my level of wikicode skills!

Going in the other direction, I could also split the fields out in this example even further

birthdate: 11th
birthmonth: march
birthyear: 1952

and so on. And for some people’s use cases, maybe that would be suitable, but for the sort of thing I do, it’s too split up.

And of course, sure, you could have

title: Douglas Adams birthdate

11 March 1952

…and so on with a tid for each bit of data.

It’s all about finding the sensible organisation of data - a tid per topic, with distinct metadata items each in their own separate fields. Neither overloading a single field with too much data, not splitting up the data to the point of making work for no clear benefit.

What we’re seeing from your example is overloading a single field. As you well note, there are benefits to it, but it reads as a “I’ve found a hammer and everything is a nail” type solution. or “I’ve found one place to store my data, and use one tool to find it”. It works, but it ignores all the other smarter tools in the toolbox that can be used when the data is better organised into distinct fields.

(note aside: the above is similar to what I use in practice in using human-readable sentance style birth and deathdates - I then use the ParseDate library from tiddlytools to calculate things like someone’s age, or how long till the next birthday, and so on)

1 Like