Author |
Message |
|
Hi Alex
Fuzzy search is not yet available. There is however a experimental 'did you mean' function which can make a suggestion if no result has been found.
The main problem with your search is that there are 14 records with "chang mai" although you were looking for "chiang mai" in reality. How can our search engine know this? Would you like to have the fuzzy search on the advanced options?
Regards
Marc
|
|
|
I agree with you. The map type control is enabled again.
Cheers
Marc
|
|
|
I am glad we agree and have changed it back.
Thanks.
Marc
|
|
|
Hallo Daniel
Ja klar, das ist sicher richtig. Aber wie kommst du an diese Daten ohne Polygone? Diese Aufstellung manuell zu machen wäre doch eine sehr zeitraubende Angelegenheit. Oder wärst du allefalls dazu bereit dies für deine Region manuell zu machen?
Gruss
Marc
|
|
|
Hi DaveK
According to the JSON rfc the mime type should be "application/json" :
http://www.ietf.org/rfc/rfc4627.txt?number=4627
I have changed it to mime type "application/json", but I am not very happy with it. It is getting a little bit annoying to open the file in a browser and with IE I get an error message and cannot open it at all. Do you have an idea why IE doesn't allow me to open it?
Mime type "text/plain" has one big advantage that it can be easily viewed with a browser. Are there any advantages for mime type "application/json"? If not I will change it back to "text/plain".
Regards
Marc
|
|
|
In der Schweiz spricht man deshalb von den offiziellen Gemeindemittelpunkten als 'Kirchturmspitz Koordinaten'. In Deutschland scheint man diesbezueglich etwas saekularer zu sein und das Rathaus zu bevorzugen.
|
|
|
Hi Mike
Do you have any reference for AI as the fips code for the Aland Islands?
We have discussed this in a previous thread and came to the conclusion that there is no separate fips code the Aland Islands :
http://forum.geonames.org/gforum/posts/list/186.page
Regards
Marc
|
|
|
I would like to re-add the maps and hybrid layers. Unfortunately some users have been concerned with copright problems with google and its data providers and we had to remove the layers.
See this thread for details :
http://groups.google.com/group/geonames/browse_thread/thread/a16df49457d91379/cafe8e3582275f49#cafe8e3582275f49
What do you think about this? Is the fear justified?
|
|
|
Stimmt, das ist eine gute Idee. Werden wir machen.
Marc
|
|
|
Hallo Daniel
Das ist richtig, die Frage welche Orte sich auf welcher Insel befinden kann mit den jetzt verfügbaren Daten nicht beantwortet werden. Dieses Problem stellt sich aber nicht nur für Inseln sondern generell für Regionen, die nicht den "administrative subdivisions" entsprechen. Bsp 'die Alpen'
Die beste Lösung bestünde darin die Umrisse dieser Regionen/Inseln als Polyone in der Datenbank zu speichern. Bei gis-fähigen Datenbanken wie Postgres kann man dann sehr einfach eine Datenbankabfrage schreiben, die alle Punkte liefert die innherhalb dieses Polygons liegen.
Dafür braucht man aber die Umrisse dieser Regionen. Und dies ist das eigentliche Problem. Wenn du die Umrisse für die Insel Amrum auftreiben kannst, ist die Lösung relativ einfach.
Viele Grüsse
Marc
|
|
|
Ich bin noch dabei die Faktoren zusammen zustellen, die dabei wichtig sind.
Ich denke es braucht eine Limite für Spitzenzeiten (max Anz Req pro Stunde), eine für den konstanten Load (max Anz Req pro Woche) und eine wie Lange der Service gebraucht wird (Anz Requests). Die Limite braucht es damit nicht jemand mehr Resourcen ziehen kann, als ihm zusteht.
Dann kann aus den drei Parametern eine Mischrechung und eine Kostenabschätzung gemacht werden. Ich denke da an drei Varianten : wenige Zugriffe mit kleinem Load, eine mittlere Anz. Zugriffe mit mittlerem Load und viele Zugriffe mit hohem Load.
Gruss
Marc
|
|
|
We at geonames are mainly using the display format with N/S/E/W, minutes and seconds :
N 48° 12' 0'' E 16° 22' 0''
in the balloon we display the coordinates also in decimal format :
48.2 / 16.36667
|
|
|
Hi Brian
Positive values are north of the equator and negative values are south. The same with the longitude. Positive longitudes are east of the Greenwich Meridian and negative values are west.
Cheers
Marc
|
|
|
Hallo Harald
Die Fehlermeldung ist ein Datenbanktimeout und tritt auf, wenn eine Query zu lange dauert. Dann wird die Query vorzeitig abgebrochen, um zu verhindern, dass Langläufer den Server lahm legen.
In den Letzten Tagen haben die Zugriffe auf die Reverse-Geocoding Dienste von geonames massiv zugenommen und die beiden Server sind an die Grenzen ihrer Leistungsfähigkeit gestossen. Heute musste ich gar eine IP Adresse blockieren, da zu viele Zugriffe von dort erfolgt sind. Das ist zwar nicht die Idee von geonames, aber es bleibt nichts anderes übrig, wenn jemand sehr viele Zugriffe macht und die Server mit der Last nicht mehr mitkommen.
So wie es aussieht müssen wir uns für die Zukunft etwas anderes überlegen und die kostenlosen Zugriffe auf eine gewisse Zahl pro Tag beschränken. Diejenigen Benutzer, die ein Service Level Agreement mit garantierten Antwortzeiten und garantierter minimaler Verfügbarkeit benötigen, können sich finanziell an den Serverkosten beteiligen und greifen dann auf einen eigenen Server zu.
Da nicht alle Dienste gleich viele Server-Ressourcen verwenden, muss ein Credit System eingeführt werden, bei dem die unterschiedlichen Dienste unterschiedlich viele Credits benötigen. Am wenigsten Ressourcen benötigen die Suchdienste und werden folglich nur wenige Credits pro Zugriff benötigen, während die Reverse-Geocoding Dienste die Server sehr stark in Anspruch nehmen und deshalb 'teurer' sein werden.
Gruss
Marc
|
|
|
Hallo Markus
1. Die Daten im 'geonames' Dump, den du offensichtlich verwendest, sind nicht exakt identisch mit dem PLZ Webservice. Du musst den PLZ dump für einen Vergleich verwenden. Für die Stadt Köln gibt es zum Beispiel mehrere PLZs.
2. Der Webservice sucht nicht nur über den Namen sondern auch über allen anderen Feldern, wie Bundesland, Gemeinde und was es sonst noch so gibt.
Beste Grüsse
Marc
|
|
|
Hi
Norway has a very complicated border line and it is possible that the boundary information we are using is having some 'holes'.
I have now implemented a fallback mechanism that gets the closest geonames feature if nothing is found using the boundary information. With this we should be able to cover the 'holes'. I will also see whether I can get hands on better boundary information.
Cheers
Marc
|
|
|
Hallo Markus
Der Webservice liefert alle Orte, die den Suchbegriff irgendwie umfassen (zB admin2) und nicht nur diejenigen die den Namen genau so haben. Wenn man genau nach dem Namen suchen möchte, sollte man den Parameter name_equals verwenden : http://www.geonames.org/export/geonames-search.html
Der PLZ dump und der 'normale' geonames dump sind zwei unterschiedliche Datenbanktabellen und enthalten nicht exakt dieselben Informationen. Die Zeitzone zum Bsp fehlt noch im PLZ dump.
Gruss
Marc
|
|
|
Hi Steven
There was a silly bug in the code. It should now work fine. Let me know if you find other problems (I don't hope so).
All JSON services support the 'formatted' (pretty printing) and 'callback' parameters :
http://ws.geonames.org/timezoneJSON?lat=-31&lng=116&formatted=true
http://ws.geonames.org/timezoneJSON?lat=-31&lng=150&callback=timezone
Regards
Marc
|
|
|
I wonder how long it will take for google to take action against this. Some days ago an open source client for google earth was forced to shut down pretty fast.
|
|
|
The postal code coordinates for Thailand have been improved. The problem with 10170 is fixed with the newest version.
Regards
Marc
|
|
|