Onderwerp: RWS bedankt....

Sinds 1795 hanteren wij de zelfde standaard voor een meter. Met wat kleine aanpassingen die niet van belang zijn voor de gewone gebruiker. Waarom wil RWS om de paar jaar een nieuwe standaard ?

3Noreen schreef :
Positie in meters geven ze ook, die staan in de velden
x_rd y_rd

Menno schreef :
Gehaald op maps.rijkswaterstaat.nl/datare...e1-9624-fee9b784138c

Dit is ruwe data (1 regel) van 1 boei:

vaarweg_markering_drijvend.9930559,BOONTJES,VW-BO -0108,BO 2-VVG 1,01-01-2005,"149392,7398","566594,5625",LK2600 MM.,3,53.05.10.15,005.18.12.68,53.05.1691,005.18.2113,4,Pilaar,"6,2",Geel/zwart,1,Horizontaal,14,"2 Kegels, punten naar beneden",2,Zwart,L,X,26,very quick-flash plus long- fl,(6)(1),(6)(1),10,#,1,Wit,#,5.30352222,53.08615278,Pilaar Geel/zwart,2223,,,POINT (654270.7856999999 5884334.456700001)

Zo'n CSV is natuurlijk gewoon een txtfile met afspraken over scheiding tussen de velden.
In dit geval een komma.
Anders dan eerst (maanden geleden) is:
- "149392,7398","566594,5625" zijn de RD-coordinaten. Nu ineens tussen quotes en met overbodige komma's
- al die punten in sommige LAT en LON
- quotes rond de kleur-benaming "6,2")
- en die komma ertussen is nieuw
- quotes rond "2 Kegels, punten naar boven"
- ook die komma is nieuw

De 1e regel bevat de namen van de velden.
Daarmee wordt de file dus een matrix met in de 1e regel de kolomnamen:

FID,vaarwater,benam_cod,benaming,inbedrijf,x_rd,y_rd,obj_soort,iala_categorie,n_wgs_gms,e_wgs_gms,n_wgs_gm,e_wgs_gm,obj_vorm_c,obj_vorm,obj_kleur_,obj_kleur,kleurpatr_,kleurpatr,v_tt_c,tt_toptek,tt_kleur_c,tt_kleur,tt_pat_c,tt_klr_pat,sign_kar_c,sign_kar,sign_gr_c,sign_groep,sign_perio,racon_code,licht_kl_c,licht_klr,opgeheven,x_wgs84,y_wgs84,vorm_kleur,s57_id,se_anno_cad_data,gdb_geomattr_data,shape

Keurig met komma's 40 stuks. Dat geeft 41 datavelden.

En dan peuteren we die tekstregels uit elkaar met een split in Python.
Dat geeft 41 aparte data items (in een List) voor de kolomnamen.
En 43 data items voor de data, omdat er extra komma's in zitten die ook resulteren in een data item.

En als er dan ook nog een licht op de boei zit komt er een extra komma bij en schuiven alla data items nog een plekje op.

Even 2 boeien naast elkaar gezet, een met en een zonder licht.
Naast de 'vreemde' lat-lon notaties zit er een hinderlijk verschil in het aantal komma's (scheiding sussen de velden als er een licht op de boei zit en die twee kleuren heeft:
Dan wordt de kleurcode tussen "" gezet en komt er een komma tussen de 2 kleurcodes.

Steeds 2 regels: boei zonder en boei met licht, alle elementen uit de data op een rij.
L en X betekenen dat het dataveld niet gevuld is.




Wat betreft de lat en lon in WGS84 met gg,gggg: die staan niet voor niets helemaal achteraan. Ze zijn pas recent toegevoegd, en mijn oude programmatje gebruikte ze niet (want afwezig).

Ha Thomas,
Wat Menno ook al zegt: die quotes horen daar, juist vanwege die kommas.
Hier staat het nog eens, misschien duidelijker?
stackoverflow.com/questions/76...commas-within-quotes

...CSV is a (moderately) well-defined format. That definition includes quotes protecting commas within them from being split points (and being able to represent literal quotes by doubling them within a quoted string). Anyone who calls splitting on commas without taking quotes into account "parsing a CSV" is wrong.

Gepost met de officiële Zeilersforum-app

Johan22 schreef :
Hoi Johan,

ik denk niet dat Menno dat zei.
De standaard bij een Python Split is dat ALLE komma's (ook die tussen quotes) als split-punt worden genomen. Zie Menno's eerdere link naar de Python beschrijving van Split.

Overigens varieert het aantal komma's in een record van boeien van 43 t/m 47.
En dat zijn niet alleen extra komma's tussen quotes, ook 'zomaar' zijn er soms extra quotes.
Dat betekent dat de data gaan opschuiven in de velden, afhankelijk van wat er toevallig op die boei zit (twee kleuren, 2-kleurig topteken, etc).

Ik heb RWS gemaild.

Baasklusje schreef :
Zoals ik eerder al zei:

Menno schreef :

---

Ik neem aan dat ze je vertellen dat er geen fouten zitten in het CSV-bestand. Hooguit dat ze niet zo consequent zijn met het formaat van de velden in de CSV.

Baasklusje schreef : Niet alleen over het scheidingsteken, maar ook wat je moet doen als je dat scheidingsteken in een veld wilt gebruiken, namelijk quoten. En wat je moet doen als je het quote-teken wilt gebruiken in een veld (dubbel quoten).

Hoe was dat dan eerst? Geen decimalen? Decimale punt i.p.v. komma? De decimalen zijn hier niet echt nodig, RD-coördinaten zijn in meters, dus de decimalen voegen precisie toe die niet relevant is.

Die zitten er volgens mij al heel lang in. Weet je zeker dat je de oude bestanden niet eerst in Excel hebt geopend en dat het bestand daarbij door Excel aangepast is?


Hoe was die kleur-benaming dan vroeger? Ik neem aan dat het niet 62 was.


Daar gaat het mis...

Orange Sunset schreef :
Ik trek deze conclusie bij nader inzien in. Deze was vooral gebaseerd op puntkomma’s die als decimalentekens werden gebruikt, maar zie ik niet terug in de ruwe data hier gepost. Dus lijkt mij inderdaad toch een prima CSV dat zonder problemen uit te lezen zou moeten zijn met python csv bijv:

Specifiek formaat is verder in te stellen dmv andere fmt parameters.

Ik heb geen oude RWSfiles meer om te kijken hoe het was.
Ik weet alleen dat mijn programmatje nu niet meer werkt
En dat het aantal split-komma's in een regel nu loopt van 41 t/m 47, afhankelijk van een of meer kleuren op een boei en van de lichten.

Ik ga CSVreader maar eens proberen.

Kan dit niet te maken met je recente W11 internationale instellingen ?

Hehe, in Excel had dat vroeger zeker impact Voor een “split” zou ik verwachten van niet. Daar geef je expliciet het karakter op waarop je wilt splitsen.

Orange Sunset schreef :
Ik heb een collega die af en toe wat problemen had met het importeren van de CSV in een tool. Bleek dat de CSV na te downloaden direct opende in Excel, en ze dan met "Opslaan als" in Excel het bestand opsloeg op een andere locatie.
Tussendoor had Excel er dan zijn eigen interpretatie aan gegeven, en het opgeslagen bestand was daarmee anders dan het origineel gedownloade bestand.

Helaas herkenbaar

Nachtvlinder schreef :
Denk het niet, de file heb ik alleen gedownloaded, niet met Excel aangezeten.
Dan is het een tekstfile die toevallig CSV heet.

daar kijk ik dan in met Kladblok (vroeger Wordpad)

Inmiddels met de CSV-reader de boel weer aan de praat.
Ik ben eigenlijk een ouderwetse programmeur die elk bitje zelf in handen gehad wil hebben.
Maar dat hoeft tegenwoordig niet meer....
Gebruik nu ook de gg.gggg waarden voor de lat en lon.
Import in WinGPS werkt weer.

En RWS gemaild, ben benieuwd naar de reactie.

Baasklusje schreef : Ouderwets misschien wel, maar programmeur...?
Dat had je in de tijd dat je hier loopt te klagen makkelijk zelf een parser in elkaar gesleuteld.

Mooi! Ik heb hetzelfde hoor (programmeur), maar dan moet je het wel goed doen en je er niet met een Jantje -split- van Leiden vanaf maken
Ik heb de dataset ff bekeken en het mooie vind ik wel dat de coördinaten in verschillende stelsels aangeboden worden, tm het rijksdriehoekscoördinatenstelsel aan toe. Ik verwacht niet dat er fouten gemaakt zijn aan RWS-zijde, het is allemaal strak gedocumenteerd en ook via bv REST te bevragen, of in XML (csv is eigenlijk de minste keus vind ik, maar wel makkelijk). Maar een foutje (serverupgrade, software wijziging..) is zo gemaakt dus ben benieuwd naar hun antwoord.



Gepost met de officiële Zeilersforum-app

Johan22 schreef :
Toen ik dit programmatje maakte, pakweg 15 jaar geleden, was CSV het enige formaat dat aangeboden werd door RWS.
En het heeft tot nu al die jaren gewerkt....

Baasklusje schreef : Weet dat ik met je mee heb geleefd in dit draadje : Keep up the good work ( ook al ben je de enige die er van profiteert)

Antwoord van RWS gehad. Snel!

Ze zijn zich niet bewust dat er iets veranderd zou zijn.
Ik heb gezegd het maar zo te laten want ik heb het al anders opgelost.

Dat is inderdaad snel!

Gepost met de officiële Zeilersforum-app

Baasklusje schreef :
Je blijft erop hameren dat dit het probleem is. Het is juist goed dat een string split functie in elke programmeertaal gewoon altijd split, ook als de separator tussen quotes staat. Het zou niet best zijn als dat niet zo is. Een split methode moet altijd werken zoals je verwacht.

Het verbaasde me dat je eerst de moeite nam om te klagen bij RWS, terwijl je wist dat het parsen van de CSV mogelijk aan jouw kant niet goed ging. Anyway, inmiddels is het opgelost dus prima.

Volgens mij is het leermoment: een string-split methode toepassen maakt je code nog geen volwaardige parser. Een parser - zelfs bij CSV - vergt meer logica die zich houdt aan een gedefinieerde standaard. Daarvoor is het altijd het goed om eerst even te kijken of hier een bestaande library voor is, voordat je in de valkuil stapt door het wiel opnieuw uit te vinden (hoe aantrekkelijk dat voor een programmeur soms ook kan zijn).

Ik vond nog een paar oude versies, toen ze nog elke twee weken als csv op vaarweginformatie.nl werden
gezet:

• Scheidingsteken was toen een ;
• Er zijn in de loop der jaren een aantal kolommen bij gekomen: S57_ID, OBJ_SOORT, IALA_CAT
• De kolommen Y_RD en X_RD zijn verwisseld
• Quotes rond 2 Kegels, punten naar beneden waren niet nodig, want schedingsteken was een ;
• Quotes rond Y_RD;X_RD waren ook niet nodig, want schedingsteken was een ;
• X_WGS84;Y_WGS84 hadden in 2012 een decimale komma, later een decimale punt
• N_WGS_gms, E_WGS_gms, N_WGS_gm en E_WGS_gm hadden toen ook al een heleboel punten

In die 15 jaar heb je dus wel vaker een wijziging aan je programma moeten maken, in ieder geval toen het van ; naar , ging


171010_DNZ_002a_markeringen_drijvend.csv (2017-10-10)

120817_DNZ_002a_markeringen_drijvend.csv (2012-08-17)

Menno schreef :
Zekers. Vroeger <2011 deed ik dit in Excel.
Regelmatig deze wijzigingen tegengekomen, die overigens vrijwel allemaal onnodig waren; ze verbeterden de data niet.
Ik was het al een beetje gewend

Overigens zijn de formats ook niet in elk record consequent gebruikt.
Zo is er af en to een X om een leeg veld aan te geven, soms een L en soms de tekst 'Niet toegewezen'.
Ook het gebruik van komma's is niet altijd duidelijk.