It did not work in Apple Maps, as my illustrations showed. Both 75008 and 75020 returned Paris, France not an arrondissement. DEVONthink reports the same thing as Apple Maps. And you were specifically mentioning using a zip code.
PS…
Sorry but I have to disagree : in Plans, “75020” returns “75020 Paris”, the correct and complete address / Zip Code. And places a pin
at the correct location, the center of the “20 ème arrondissement de Paris”. Same for 75008, the returned location is the right one, the center of 75008 Paris, not juste ‘Paris’ like DT does.
DT returns just ‘Paris’ and drops the rest of the location address.
Same thing for ‘Belle-Île’, as shown before 
: Plans returns the right and complete information and location, DT does not, whatever I use the name of the island or the Zip Code.
Did you could try to enter these locations I described on your side ?
In this example, it’s because Plans is waiting for you to choose between two homonyms locations, one in France, one in Belgium. Once you clicked on the right one, Plans displays the ‘Belle-île’ island, and not Lorient.. No issue if you type instead the complete name ‘Belle-île-en-mer’.
The issue is not that DT doesn’t find the address, it’s the misplaced or incomplete returned location.
My screen captures already showed you the exact information I received.
And the point about “Belle-île” is there is not one choice. There are two. DEVONthink isn’t making up locations. It is receiving information about the provided location and populating the geolocation field. If you know there is a “Belle-île” in Belgium then it’s incumbent on you to give it more information. If I enter Belle-île France in the Geolocation field, it resolves to Le Palais, Brittany, France. And again, this is received information.
In fact, if I type 75020 in the Geolocation field, it returns a location in Texas in the US. This is unsurprising given I am in the US. I have to type 75020 France to resolve the Parisian zipcode.
1 Like
I agree, the returned location is, as previously explained, a part of the island, ‘Le Palais’, one of the four cities in Belle-île -probably the largest or most populated one- instead of Belle-Île island itself.
As to any of the technical aspects of this mechanism, development would have to comment on that.
1 Like
I get this, no problem. The issue is not the search, but the returned result which is not accurate after the search terms and the entered address are found and OK.
I would appreciate that, there should be an explanation. Maybe because of the European vs US way of handling and ‘mapping’ the addresses, Zip Codes and actual locations ?
Nonetheless, an additional / alternative geolocation way, using GPS coordinates, able to display them on a map, would be very welcomed by all people handling geographical data, not just addresses, therefore needing the precise and actual location of their items.
Thanks for your tests and answers.
France has a very particular way of associating political and ZIP code boundaries. 75020 is the 20ème arrondissement of Paris, 75005 is the 5ème etc.
But this ZIP code/administrative unit relationship is far from universal. In Germany, for example, the post office assigns ZIP codes whichever way it wants. Until the early 2000s, 1000 Berlin 36 designated one part of Kreuzberg, 1000 Berlin 65 another one. Now we have five digit codes and all bets are off.
Of course DT relies on an external service to resolve addresses to coordinates. But to expect this service to return what you think relevant in every case is irrational. Especially if the service is Apple Maps.
Instead, you should use latitude/longitude pairs and use whatever service you deem reliable to do reverse encoding. But even then, one service may return Champ de Mars and another one Tour Eiffel for the same set of coordinates.
1 Like
DEVONthink uses macOS’ Core Location framework.
1 Like
Exactly, and I suspect DT may not use the right structure/hierarchy for the country the search is made in. Maybe a kind of unspecific global reference system ?
The French administration provides an open source reference system
used among others by the French Post who, in the case of 75020 Paris you mentioned, returns the expected result :
Which could means that either the reference system used by DT is not the official and accurate one, or that something in the way it is processed doesn’t work well : in the case of Paris, DT picks the ‘parent’ level (the whole Paris) instead of the specified arrondissement.
Though even if it would work properly, the ‘Geolocation’ field is rather a ‘City’ field.
- I can’t choose a part of a city area, even if it has a specific zip code (Paris case we discussed above, and other cities like Nice..),
- nor an broader area (Canton, Departement, Région, Parc National…), even if an official administrative échelon. France is divided in 18 Régions and 101 Départements. But ‘Alpes Maritimes’ (Departement #06) will return ‘Nice, Provence-Alpes-Côte d’Azur, France’ instead (the Prefecture city).
In addition to that, it doesn’t propose me choices if it’s not the unique exact and complete name :
- ‘Yosemite National Park’ will return you ‘Yosemite National Park, CA, États-Unis’
- ‘Yosemite Park’ → ‘Bridgewater, SA, Australie’.
- ‘Yosemite’ → nothing (a beep).
On the reverse, Apple Plans or Google Earth will propose a list of similar names, and displays a choice to make in the case of homonymy.
Therefore, I thank you for leading me to the much more flexible Custom Metadata solution, that I dig in since your post. Aha Moment. Better for my use case than the rigid, incomplete and sometimes inaccurate ‘geolocation field’, and than the cumbersome Nested Tags I had primilarly chosen.
A real GPS Geolocation is still needed IMO.
Cheers
It may do, but why then would DT return different results than Plans (or Google) ?
Google most likely uses its own services.
What else do you expect? Reasonably, I mean. There’s France. Then there’s for example Germany, with official keys for federal states, counties, cities, parts of cities (yeah, no one outside the statistics office uses these, but they’re are there). There are countries where cities have two different names (Brussel vs Bruxelles, eg). And then we have different names for the same place depending on language: Warszawa vs. Warsaw vs. Warschau vs. Varsovie.
Should DT implement different (inverse) geo-encoding routines for over 160 states in the world? Would you be willing to pay for that?
Each DT record has latitude/longitude fields (see the scripting dictionary). You can access these values with a script. And than you can feed them to what ever service you want. Check out the “Script Actions” part in the “Smart Items” section of the online manual – simply type “longitude” in the text field under DT’s “Help” menu.
What you see in Apple Maps (“Plans” in French) is perhaps not what the Core Location framework returns. Apple is known for having private frameworks, and apps are known for massaging data into something they deem more useful for the user. For a simple reason: There may well be several objects tied to the same pair of coordinates. Think of an office building with hundreds of offices, all having the same coordinates. What should reverse geo-coding give you in this case?
Then there’s the process involved with your specific queries. “Belle-île en Mer” is not a coordinate. It is (at best) an area. But reverse geo-coding works with a coordinate, figuring out the address or POI at that coordinate. What do you expect if you don’t pass in a point but an area to happen in that case? IMO, all bets are off in that situation.
Just use a custom meta data field and enter whatever you want for “location” in it: the name of an island, the ZIP code of an arondissement or a quarter in Nancy. That way, you have exactly what you expect.
2 Likes
I don’t know much about these technical aspects, my supposition was that DT would use the relevant/official national postal open data for each country.
I understand that, I don’t in know in fact if DT relies on coordinates or on addresses/Zip codes repertoire. It seemed to me it was the second case.
Interesting, I’ll explore this. Though I would need to export the data in another software to display them on a map I guess ?
Yes, In this particular tricky case, Belle-île regroups 4 cities, all with the same Zip Code, the main one, Le Palais, being the ‘Bureau distributeur’ I guess.
Apple Plans displays the whole area/Island, DT returns the main city corresponding to the Zip Code. Which suggest DT probably relies on these ZIP codes database. But doesn’t explain why it doesn’t in the case of Paris.
That’s the path I’m now following, thanks to you
There are LOTS of countries in the world all with their idiosyncrasies. £$€.
1 Like
If you provide the name of a street, a city, a county or whatever other conceptually two dimensional object, a mapping software may (!) find the relevant area for it. That depends on the quality of the data it is using. For example, passing in the name of a city quarter in Europe might give you the boundaries of that quarter. Though I wouldn’t be too sure of that to work in lesser travelled regions, say Northmacedonia.
Now try “Khar Yalla” in Google Maps and Apple Maps (“Plan”). The first one will give you the corresponding quarter of Dakar. The second one not. OTOH, Google is sh*t in China, and Apple even knows the public transport routes and schedules (but gets opening times wrong).
Every service uses a different set of data. Some may have referenced publicly available sources like your French ZIP codes. Others haven’t. And none will request such a type of data in real time, simply because the relevant service may be down.
So, in the case of DT it boils down to
- they rely on an Apple mapping framework
- Apple’s map support is better than it was, but it’s still not very good in many parts of the world
- consequently, you will not always get what you want with geo values in DT
I don’t know about “regrouping”. There are four cities located on the island. What Maps displays is obviously the area, because you asked for the area. And it also says “Morbihan, France” (at least on the iPad). Which seems to be an administrative region to which the island belongs. But what happens when you try to get a route to the island? It doesn’t know one for cars or pedestrians, but it sends bicycles to the geographical center of the island. Ie, a point And that is the coordinate associated with the island. Possibly what DT uses.
DT relies on Core Location. What that one does is Apple’s secret.
1 Like
I apologise, my English is not very rich nor always pertinent or accurate 
I meant that there are four administrative cities composing Belle-île. Morbihan is the ‘Departement’ (101 departments in France) the Belle-île area and these 4 cities belong to.
That’s true, I just checked, as you can’t drive all the way to BI, and Apple plans doesn’t seem to be always aware of ferry lines. Thanks to its own sauce, Google Maps includes the ferry in the proposed route.
Yes, Apple Plans is aware of the ferry lines for long distance bicycle journeys. Not for pedestrians, but it will if you set a closer -and more likely- starting point -Nantes for example-, as it probably considers that probably no one would walk 1000 kms to go to Belle-île.
Yes Apple Plans displays a pin at the geographical/geometrical center of Belle-île.
DT chooses to return the main city instead (Le Palais), probably relying on its Zip Code being the same than the 3 other smaller cities.