ws.geonorge.no
Norwegian standard Places with longitude and latitudes.
I hope that there is someone who knows a little about JAVA and knows how to import JSON files into a database as it is possible to upgrade all Norwegian place names via a free link to the Norwegian Mapping Authority.
The municipality number for Oslo is 0301 and via this link we find that Oslo has 6127 place names:
Bergen municipality in Western Norway has municipality number 4601, so the link works easily by changing the number 0301 in the link above to 4601:
An overview of all the country's municipality numbers and municipality names per 01.01.2020 (excel) can be downloaded or read directly on this website:
コメント
-
I don't know the answer for your question. But I looked into the first link and searched some of those places. I tried about 20 and only 3 of those were not already in the FamilySearch places database. I fear that if those files are just imported into FamilySearch places database, many places will be twice after that and there will be much and much of unnecessary work for those volunteers who edit FamilySearch places databace when they have to delete all those duplicate places. Please do not import anything. That Norwegian database can be used as a help tool and source when editing those places which already are in and then adding if something is missing.
0 -
If someone had access to read the database using SQL or whatever and then compare to the JSON files by looking at names and how far away from the coordinates things are, then you could create another list with the places attached to PIDs of places that need info changed (like dates if you had that) and then ones to just add. Then a human could verify what to actually add and add manually. That would automate some of the process but not too much. But i'm not sure that will happen. I wish I could have acces to the Dutch places on FS Places so I could come up with that remaining list easily lol.
0 -
Today, it is considered an old, obsolete method to manually change data when there is direct access to MAP-databases via the API. Everything maintained by the Norwegian state. Historical place name data is also available
0 -
Those who have already entered standard place names for Norway, I do not think have been resident in Norway.
Yes, the place names should be replaced with what is actually registered in the Norwegian Mapping Authority so that they are accurate and adapted to the map of Norway, or better, - be directly linked to the map database using the API.
The case is that place names contain local history and in this local place you will be able to find families who have lived over time. There are very many place names that are like in Norway, e.g. The name MO or NES. If you do not know which parish, municipality and county the place name is associated with, preferably with GPS data, FamilySearch registration will then be incorrect, and unfortunately there are millions of errors in this database.
When place names in FamilySearch are correct, the next step is to link the data to the Historical Population Register.
https://www.nr.no/~holden/HBR-english.pdf
0 -
I'm a bit unclear about some of your comments. When you say "unfortunately there are millions of errors in this database," are you referring to Family Tree or to the actual Places database? What type of errors are you referring to?
Also, when you state "If you do not know which parish, municipality and county the place name is associated with, preferably with GPS data, FamilySearch registration will then be incorrect," and refer to "FamilySearch registration," do you mean in Family Tree or somewhere else? Also, I'm not sure what you mean when you say "preferably with GPS data" since all place names in Family Tree have GPS data and "standardized" place names are just text representations of the actual GPS data that underlies them.
Regarding your comments that FamilySearch should do a massive import from an available database of Norwegian places, that is exactly what they did when the Places database was first created sometime before 2012. You can the evidence of this on all of the original entries under the citations for those places.
For example, Haukås in Alver, Vestland, Norway (Place ID: 591710, see: https://www.familysearch.org/research/places/?searchTypeaheadInputText=haukås, hordaland&text=haukås, hordaland&focusedId=591710) has the citation "Online - Gazetteer NGA, 260297"
This citation is a reference to the National Geological Association database of place names throughout the world. Unfortunately it always takes me a long time to figure out again how to get back to that original reference. It is not very easily accessible.
I assume they used this database import as part of creating the database for the entire world. I'm sure that initial import was completely automatic.
Unfortunately, from what I have seen the NGA database often used different GPS co-ordinates than Kartverket. I see very commonly that they differ by less than a couple of miles.
Also unfortunately, there was apparently an administrative decision early on that is really a problem for Norwegian place names. Someone decided that it was sufficient to just have the place name and the fylke and that the kommune was not needed. This seems to have been compounded by another decision to get rid of "duplicates" in a fylke.
There is ongoing work to correct these problems. While the database used to just have just Haukås, Hordaland, Norway, which is the example listed above, there are now entries for Haukås in Kvam, Kvinnherad, Sveio, Varaldsøy, Strandebarm, and Finnås, all of which are in Vestland.
So while I do think your idea has great merit, I think there are major difficulties. The first being, is that that Norwegian database only has current names. That is a big problem for the part of Norway I mainly work in. The vast majority of my wife's ancestors were born in Hordaland which does not exist anymore. As of January 1, 2020, Hordaland was merged, as you know, with Sogn og Fjordane to create Vestland. If following generally recognized as correct practices, no one born on or before Dec. 31, 2019 should have a birth place recorded as being in Vestland but that is all the Norwegian database has now.
The second problem is that the Places database currently has such a huge number of place names for Norway which are linked to places in Family Tree via the standardization process. Throwing out that part of the Places database and starting over with a new import would remove all the standardization in Family Tree, leaving red exclamation points for every place name in Norway unless there was some way to merge the two databases. Someone would have to come up with a routine to decide when two names were close enough and when GPS co-ordinates were close enough to decide two places were actually the same.
The third problem is that, if I am assuming correctly that the database you refer to is the bases for Norgeskart ( www.norgeskart.no ), that database is too complete. It contains every single bruk within each farm as well as every mountain, river, stream, bridge, down to every little bump in the road. A vast number of these are not useful genealogically speaking.
To summarize, it would be great to have a massive import of correct place names with GPS coordinates because there are a lot of missing place name in the database, but the practically and ability to do this without making things worse raises concerns.
0 -
Philip Skolmoski of the authorities team Sandy Remote Operations Center will begin to work on it. Thank you for your input.
0 -
Just be sure to do this properly and not lose any historical time periods, variant names, wikipedia links or citations and do not introduce any duplicate places.
Also, be sure to screen out unneeded place names. For example, the community of Stord has 66 main farms and one town. The database referenced here has over a thousand place names that include the airport, bridges, schools, lighthouses, fjords, protected wilderness areas, lakes, rivers, inlets, straits, marshes, mountains, and many other features that are not residences and should not be in the Places database.
Also, there are a plethora of bruk names. These are sections of farms that still are viewed as part of the main farm. If these are entered in the Places database, they need to be a child of the parent farm. For example, Gjerde is a bruk and part of the main farm (gård) of Kyvik. It needs to be entered in the Places database as Gjerde, Kyvik, Stord, Hordaland, Norway unknown-2019 and Gjerde, Kyvik, Stord, Vestland, Norway 2020-Today. It must not be entered as Gjerde, Stord, etc. because that would be insufficient to identify it. In particular because there is also a bruk named Gjerde under the Orninggard farm. These bruk do appear do be designated differently in the database, at least some of the time, but there is no designation there as to what farm they belong to.
0 -
I think you have good points here Gordon and the only thing that is perceived as correct in the National Geological Association database in this context is the actual geographical point for a specific place in Norway. Names, spellings and affiliation to the general level, such as parishes, municipalities and counties, are variables over time.
I have therefore created a case in Karverket to find out if the Mapping Authority's ID (ssrid) is the same over time so that it is possible to create place names based on different periods.
If I know the bureaucrats right, I will get an answer to this once in the new year and will give an update.
I can add that I am working on a privately funded project where the idea is that every geographical point that has had a population over time, has a local history that is interesting in genealogy. A link between the physical place and databases such as local village books and registers, historical population registers, church registers, protocols and censuses will hopefully become available over the Internet so that anyone can look up databases. An example is that today one is dependent on having a Norwegian IP address to access such sources, but this can be solved if databases such as the one I am looking for are located in Norway.
0 -
I feel the need to comment on Gordon Collett's post as he writes that place names are unneeded in a place database. In genealogy, everywhere in the world contains a story that can be interesting, some have sunk in a ditch or encountered a reef, some have died on a mountain or drowned in a swamp.
Place names must be categorized and we must think like a computer that takes one tenth of a second to filter out what kind of place name we are looking for.
All place names have a geographical address with longitude and latitude and only the geographical address (numbers =ID) is the default name.
All other names have only a periodic history in the form of spelling and pronunciation. Even belonging carries a history as many places and countries have been changed, for example through a war or municipality relocation and names. All of these are variables that should belong to the standard geographic address (ID).
0 -
Sorry, I got a little sloppy in my terminology. I was referring to the fact that there needs to be a balance between too few places names and too many place names in the Place Names Standards database.
Too few and we get everything in Hordaland standardized as just Hordaland with the same pin on same spot on the map for every event.
Too many and we get a bloated database full of hundreds of thousands of place names that will be used exactly once after spending millions of working hours making sure each entry is correct.
The beauty of Family Tree's dual place entry system is that we as users can put just as much detail as needed in a place name. We are not stuck with the standard:
Rødland, Lindås, Hordaland, Norway
We can enter:
Twelve feet north north west of the front door, Setstølen, Rødland, Lindås, Hordaland, Norway.
Yes, these two will end up with the same map pin, but if these each had their own map pin, they would only be a few millimeters apart on the map anyway.
0 -
OK, I see your point.
My goal is to find a solution that standardizes your place (Lindaas, not Lindås) so that we can more easily find who lived in the relevant place according to the Norwegian population register. Census on Lindaas:
0 -
In this dialogue, it is appropriate to say that all Norwegian properties mentioned in Professor Olaf Rygh's famous book of works in 19 volumes "Norske Gaardsnavne" have all plot boundaries. This means that it should be possible to obtain a place name ID which is a common reference to a residential address.
So it's just nonsense here to put sticks in the wheel to claim that hundreds of thousands of place names will appear in a database of place names.
0 -
Before changing the subject here, let's go back to your original post and my concern with it.
My comments were based on the fact that the Norwegian Mapping Authority's database does not contain just residences, it contains the names of every single geographical feature. At probably 99% of those geographical features, nothing of genealogical importance ever happened and they are never mentioned in any parish record.
This place, for example, probably does not need to be in the FamilySearch database:
However, it is in the database you reference when using municipality number 1811:
The other problem with this database is that it is only concerned with current place names. In the list of municipalities you link to, it shows that the former municipality of Lindås (as it is spelled in that listing and has been since 1921) no longer exists. Searching the Norwegian Mapping Authority's database on its municipality number gives no results.
Now, on to your new topic. The database of Olaf Rygh's work at
https://www.dokpro.uio.no/rygh_ng/rygh_felt.html
would be a great database to somehow input into the place names database. This, also, would have to be done with care. In some areas of Norway all the farm names listed by Rygh are already properly in the database so any routine to transfer place names would have to carefully avoid duplication. Other places in Norway have few if any of the farms entered and having blocks of names entered as a starting point would be a nice advance.
However, dumping in those farm names would still be just a starting point because FamilySearch's goal is to have the entire history of a place's name in the database and even Rygh does not include that.
Regarding your statement that it should be possible to obtain "a place name ID which is a common reference to a residential address," FamilySearch is developing just that. All place names have a unique numerical ID assigned to the point on the globe for each place as identified by latitude, longitude, and time period.
Let's take as an example the farm Dalland. Lat: 60.1563, Long: 5.6008
The Norwegian Mapping Authority database lists this as:
ssrId:78209 Dalland, Bjørnafjorden, Vestland
The Olaf Rygh database lists this as:
(No ID number I can see) Dalland, Strandvik, Søndre Bergenhus
FamilySearch Places lists this as:
ID: 10915545: Dalland, Os, Hordaland, Norway, Unknown to 1854
ID: 10915546: Dalland, Fusa, Hordaland, Norway, 1855 to 1902
ID: 10915547: Dalland, Strandvik, Hordaland, Norway, 1903 to 1963
ID: 10915548: Dalland, Fusa, Hordaland, Norway, 1964 to 2019
ID: 10937166: Dalland, Bjørnafjorden, Vestland, Norway, 2020 to Today
(Yes, until 1919 Hordaland was actually called Søndre Bergenhus but since the boundaries were the same and since the Norwegian Archives categorizes all the records in the indexes and databases as being for Hordaland, following the lead of the archives and not adding yet another place name level was apparently viewed as sufficient. This may be different in other parts of the country when the change from Amt to Fylke also led to dramatic boundary changes, as did the recent change from Hordaland to Vestland)
I would be all in favor of any process that could efficiently and accurately add additional genealogically significant place names to the Places database as long as it did not introduce any duplicate place names that would have to be manually searched for and merged, particularly for those areas in Norway for which that has already been done, and would not damage place names, such as Dalland, that are already thoroughly documented in the database.
So if someone could take the Norwegian Mapping Authority database, pull out data for just one municipality at a time, filter out non-residences, adjust to an appropriate level of geography (that is, not include such things as every house number), determine a way to eliminate those places already in the Places database so as to not introduce duplicates, and then introduce just those new places into the database, that would be wonderful and make a good starting point for the people currently going through the database adding reference material, citations, alternate spellings of names, and every historical time span for those places.
0 -
Yes, I work with Rygh's in Excel and use old and new municipality number + page number in Rygh:
The Norwegian Mapping Authority's place name register (SSR) consists of 1,044,531 place names that I have obtained and Rygh's place name is easy to filter out as these are also found in Excel. I have also found that the link you refer to (https://www.dokpro.uio.no/rygh_ng/rygh_felt.html) is not complete as several counties lack æ, ø and å and the database lacks southern, western, northern etc on the individual farms.
My plan is to create a web page "Historical housing register" which can be linked to the Historical Population Register which received 25 million NOK from the Norwegian state for this project. I have sent a request to the project manager, but have not yet received a response during these corona times.
0 -
I can also mention that I would like to include a column with reference to the village books as the tables of contents are usually based on Rygh's database. I welcome ideas for moving forward in this work
0 -
Sounds like an ambitious project. I wish you well with this.
0 -
Can you tell me Gordon, where and how I can find FamilySearch Places lists ID so I can enter this as a ID-period reference in my Rygh database?
0 -
The reply you don't want is that they are right there in the database:
I'll message you a better answer.
0
