TOPIC:

Hi,
currently i'm trying to consolidate the geographic data of my webtrees Installation (ahnen.hompfs.de - which is a webtrees 2.0.17 installation).
For this purpose, i built a dataset for germany out of geonames data with my
intended structure, which is for Germany "Ort,Landkreis,Bundesland,DEU".
Additionally, i downloaded and installed the provided geographic data for France from the webtrees download location.
When i edit places, the automcomplete function seems to not search in this consolidated data.
It looks for data in the gedcom tree, and then - if configured - for data from geonames.org.
The webservice for geonames.com delivers another data structure for germany "Ort,Regierungsbezirk,Bundesland,Deutschland".
Would it be possible to implement this function, or am i the only one who sees the need for it ?
Kind Regards
Tom

Hello,
i don't know if i'm the only one who finds it useful to make autocomplete search in place_locations table when editing places.
I have no doubt, it will help me in keeping the _PLAC records more consolidated, even when others - newbies - help in completing the tree.
So, yesterday i implemented this function for my site and could provide a PR.
What is your opinion Greg?
Kind regards
Tom

Hello,
Indeed, place_locations is not used for autocomplete (even before 2.0), but rather for geolocation (i.e. retrieving the latitude/longitude data). So, it firsts looks into to the existing GEDCOM places (the places tables), then to the autocompletion service provider(s) (Geonames only in 1.0 & 2.0).

I am not sure how familiar you are with webtrees developments, but there are improvements in the upcoming 2.1 regarding places autocompletion and geolocation, with in particular the capability to lookup on various autocompletion service providers (including GeoNames, but not only). You could create a custom module implementing the ModuleMapAutocompleteInterface interface where the source is the place_locations table, or even - if your mapping between Geonames and your desired format is simple enough - inherit from the GeonamesAutocomplete module and reformat and return the response to your requirements.

> i don't know if i'm the only one who finds it useful to make autocomplete search in place_locations table when editing places.

The problem is privacy.

The wt_place_locations table contains all places from all trees.

If you use it for auto-complete, then a user in one tree could find all the places in another (private) tree.

As Jon says, there are currently changes being made that will allow many different sources for place-name auto-complete. One of these could be the wt_place_location table.

>The problem is privacy.
>The wt_place_locations table contains all places from all trees.
>If you use it for auto-complete, then a user in one tree could find all the places in another (private) tree.

This is not exactly true. With autocomplete searching in wt_place_locations a user could find all data which is in wt_place_locations, without knwoing, if it is ever used in any other tree.
In my wt_place_locations there are about 20000 rows with nearly all citys in germany and parts of the france geolocation data which is offered as a download on the webtrees site. Here IMO a user would definitely not know if the data is used anywhere.
But i get your point, that's why i made the search in placelocation configurable on the admin page - default disabled. So if one suspects privacy issues, he would just not enable this functionality. But for anyone who uses i.e. the geographic data downloadable from the webtrees site, it would be a great help in keeping _PLAC records consolidated wihtout even using an external webservice...

After i got a request by email of another webtrees user regarding the autocomplete of places by searching wt_place_locations table, i would like to bring this topic to front again.
I created PR#4079 on github, which still merges fine on 2.0.19 and runs on my site for a couple of months now without problems. It can be switched on in the admin interface (default is off)
As i explained before, the privacy issue is IMHO not really relevant, because a user would not know if the so found places data is just beeing imported for the autocomplete purpose or belongs to a real PLAC record.
Greg, I know, that you are very busy getting the migration to 2.1 done, but if you've got a spare moment of time left ;-) i'd be glad if you looked at the PR and considered merging it.
TIA
Tom

b.t.w the forum software spits out many errors in the last days i.e. when pressing the reply button. Is this a known issue?

tkempf wrote: b.t.w the forum software spits out many errors in the last days i.e. when pressing the reply button. Is this a known issue?

Yes, as discussed in the thread that was on top of the recent posts list because nobody can create a new topic, reply non-quick or edit existing posts

www.webtrees.net/index.php/en/forum/4-cu...fe-span-age?start=20

Ich schließe mich der Meinung von tkempf an.
Es gibt viele Orte bei den Webservices (geoname,...) die zwar eine Hierarchie bei Autocomplete liefern, aber sie sind nicht zielführend.
Ein Beispiel:
(places ist noch leer !)
Eingabe von "Aachen" ergibt "Aachen, Nordrhein-Westfalen, Deutschland"
das ist nicht korrekt, der Kreis wurde unterschlagen!
Es muss aber lauten "Aachen,Städteregion Aachen, Nordrhein-Westfalen, Deutschland"
(Wahrscheinlich werden die "falschen" Variablen aus dem JSON von geonames.org herangezogen.)

So ist keine Hierarchie aufzubauen: die Reihenfolge ist gestört.
tkempf hat nun mit Aufwand eine CSV Datei erzeugt und das Programm via PR#4079 angepasst.
Diese Lösung läuft unter 2.0.19 korrekt!
Diese Datei kann importiert werden und die Daten landen in place_location.
Hier wird nun die korrekte Hierarchie aufgebaut.
Bei autocomplete werden die korrekten Daten angeboten.
Es hilft ja nicht nur den Ort mit der falschen Reihenfolge nach "place" zu übernehmen.

I agree with the opinion of tkempf.
There are many places at the webservices (geoname,...) that provide a hierarchy at autocomplete, but they are not purposeful.
An example:
(places is still empty !)
Entering "Aachen" results in "Aachen, North Rhine-Westphalia, Germany".
this is not correct, the county has been omitted!
But it must be "Aachen,Städteregion Aachen, Nordrhein-Westfalen, Germany".
(Probably the "wrong" variables from the JSON of geonames.org are used).

So no hierarchy can be built: the order is disturbed.
tkempf has now created a CSV file with effort and adapted the program via PR#4079.
This solution runs correctly under 2.0.19!
This file can be imported and the data ends up in place_location.
Now the correct hierarchy is built here.
With autocomplete the correct data are offered.
It doesn't help to import only the location with the wrong order after "place".

Hi,
for those who are interested in this function, i created a v4 module for 2.1.0-alpha2 which implements the autocomplete via place_location table.
The module can be found here github.com/tkempf/autocomplete_place_location .
Kind Regards
Tom

Many thanks to tkempf. This is a good solution!

tkempf wrote:

for those who are interested in this function, i created a v4 module for 2.1.0-alpha2 which implements the autocomplete via place_location table.
The module can be found here github.com/tkempf/autocomplete_place_location .

Thank you for your module, Tom.
It's good that it comes up disabled for those who have privacy concerns.
On the other hand places are only places. When the place hierarchy is not disabled it also reveals places.
I would appreciate when it would again become part of the core. The module helps to avoid duplicate creation of new locations when more than one tree is installed.