This tool should perhaps be compatible with linux, as i am one of those that tries not to use windows. There is also a Python script here : http://pastebin.com/qUcH4mRe It looks like it checks/compares data against the Elveg database. There is also some challenge to include road blocks, the Elveg segments must sometimes be splitted because they are in the same place as a existing node that can be merged, even there is some nodes that have coordinates that are on a line between road nodes. I believe that Geir Ove Myhr can explain this better.
At least, there is no good tools and example data that makes a import from the Elveg database feasible. In my opinion this must have priority,because the address database was recently imported via voluntary communal work. The status is available here: http://osm.beebeetle.com/addrnodeimportstatus.php On 11. jan. 2015 14:09, Gnonthgol wrote: > Den 11. jan. 2015 13:45, Thomas Weidner skreiv: > > Yes, I totally plead guilty of NIH syndrome here. One thing I did > not seem to be possible with sosi2osm is collecting all roads and road > route numbers and output a corresponding relation at the end. But > then, at some point I stopped looking at it. > > This is not possible in sosi2osm. I thought about such cases and > figured it was better to just postprocess the osm files in good tools > rather then try to implement such tools myself. sosi2osm is only > converting objects directly and allows you to run the tags through a > lua script as the tags in SOSI is hiriarchical > and even allows multiple values. > > > If sosi2osm is the project to go and you can maybe only copy some > SOSI->OSM tag mapping from my source this would also be fine for me. > > Thank you. > > > Unfortunately Java has no nice way of switching the input encoding > while reading the file, so I put it on the TODO list, but it should be > fixed. > > The simple hack here would be to just reopen the file once the charset > is determined. > > >> You have probably seen the SOSI standard definitions over at > http://www.kartverket.no/en/SOSI-Standard-in-English/SOSI/ > > I read the Norwegian standard document about the SOSI format (using > google translate) > > These are the same files but translated manually. > > > The BNF is international ;). I think apart from the encoding issue, > there are two problems: > > > 1. The parser does not handle data values correctly, strings ("a > quoted string") are not parsed correctly > > I have even seen SOSI documents containing strings that should be > quoted but are not. > > > 3. to correctly understand files you seem to have to read the > definition files. For example "..VNR X Y Z" is really shorthand > notation for "..VNR ...VEGKATEGORI X ...VEGSTATUS Y ...VEGNUMMER Z" > > The FYBA library is also missing this feature. > > > The FYBA C library seems to be pretty complete, but also pretty > ancient. Maybe having an alternative is not that bad. > > If there were a nice modern alternative we could use I think even the > officials would prefer it. The problem with making parsers though is > that you have to handle a lot of almost standard documents too. FYBA > does a very good job at this at the moment but it a pain to get to > work. If I could get FYBA to work on > windows I would have loved to publish a binary of sosi2osm for windows. > > Gnonthgol > _______________________________________________ > kart mailing list > [email protected] > http://lists.nuug.no/mailman/listinfo/kart > > > -- Håken Hveem Gnup/PGP key ID: 45793A72
signature.asc
Description: OpenPGP digital signature
_______________________________________________ kart mailing list [email protected] http://lists.nuug.no/mailman/listinfo/kart
