[OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015
Just van den Broecke
Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
Top10NL via PDOK beschikbaar gekomen.
NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
beschikbaar gesteld:
Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
BAG: http://data.nlextract.nl/bag (ook CSV)
Hartelijke groet,
--Just
_______________________________________________
Talk-nl mailing list
Tal...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl
Milo van der Linden
Hallo Just,Klopt het dat in het csv file alleen de Adressen uit plaatsen uit Noord-Holland zijn opgenomen?Ik ben eigenlijk op zoek naar een extract met: Openbare Ruimte, Woonplaats, Gemeente.Kan je me daarmee helpen?met vriendelijke groet,Thomas.
Op zondag 26 april 2015 23:56:13 UTC+2 schreef Just van den Broecke:
Sorry voor cross-posting.
Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
Top10NL via PDOK beschikbaar gekomen.
NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
beschikbaar gesteld:
Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
BAG: http://data.nlextract.nl/bag (ook CSV)
Hartelijke groet,
--Just
Just van den Broecke
> Hallo Just,
>
> Ik zie dat je de BAG dump hebt gewijzigd. Ik constateer de volgende
> kleine issues:
>
> 1. role kademo zit in de dump. Die role zou eigenlijk niet mee moeten
> worden genomen.
lijst:
"@Edward: "owner kademo" geeft welliswaar error maar is niet fataal.
Owner uit dump verwijderen is wat kip/ei. Volgens manpage pg_dump (niet
-o maar -O moet/is gezet in pg_dump):
"-O
--no-owner
Do not output commands to set ownership of objects to match the original
database. ....To make a script that can be restored by any user, but
will give that user ownership of all the objects, specify -O.
This option is only meaningful for the plain-text format. For the
archive formats, you can specify the option when you call pg_restore."
Kip/ei: de dump is in "custom" format (-Fc), dus --no-owner is niet
mogelijk. Om te restoren in PGAdminIII is "custom" het meest praktisch.
Compressed plain text (SQL .zip) deden we eerder. Echter daar hadden de
meesten problemen omdat dan meer handmatig dient te gebeuren.
Zie ook README:
http://data.nlextract.nl/top10nl/postgis/README
Suggesties hier welkom."
> 2. Voorheen had de bag een schemanaam overeenkomstig met de datum. Ik
> gebruikte dit om de import te controleren en dan in mijn schema
> bag_actueel views te maken op de meest actuele, gelukte import. Ik ben
> blij dat jou schema bagactueel heet zonder "_" want anders zou ik echt
> klem hebben gezeten met mijn "hot" import. Ik kan namelijk geen downtime
> gebruiken op de bag database.
>
> Zoals ik al zei; kleine problemen. Op zich niets storends, maar ik moet
> zeggen dat ik de vorige methode eigenlijk beter vond.
Tja dat is het punt: iedereen wil net weer iets anders. Zie allerlei
mails eerder. Schemanaam met datum zit iets in. De vorige methode gaf
weer veel problemen bij de PGAdminIII-ers.
Hartelijke groet,
Just
>
> Met vriendelijke groet,
>
> Milo
>
> Op 29 april 2015 18:15 schreef Thomas Offeren <tvof...@gmail.com
> <mailto:tvof...@gmail.com>>:
>
> Hallo Just,
>
> Klopt het dat in het csv file alleen de Adressen uit plaatsen uit
> Noord-Holland zijn opgenomen?
>
> Ik ben eigenlijk op zoek naar een extract met: Openbare Ruimte,
> Woonplaats, Gemeente.
> Kan je me daarmee helpen?
>
> met vriendelijke groet,
>
> Thomas.
>
> Op zondag 26 april 2015 23:56:13 UTC+2 schreef Just van den Broecke:
>
> Sorry voor cross-posting.
>
> Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
> Top10NL via PDOK beschikbaar gekomen.
>
> NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
> beschikbaar gesteld:
>
> Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
> BAG: http://data.nlextract.nl/bag (ook CSV)
>
> Hartelijke groet,
>
> --Just
>
>
>
>
>
>
>
> --
> http://www.dogodigi.net <http://www.dogodigi.net>
> *Milo van der Linden*
> web: dogodigi <http://www.dogodigi.net>
> tel: +31-6-16598808
Milo van der Linden
Pander OpenTaal
> Sorry voor cross-posting.
>
> Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT
> Top10NL via PDOK beschikbaar gekomen.
>
> NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download
> beschikbaar gesteld:
>
> Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/
> BAG: http://data.nlextract.nl/bag (ook CSV)
Ik heb wat analyses gedaan op de export van BAG in CSV en heb de
volgende fouten gevonden:
ERROR dubbele spatie in straatnaam "Burg. v. Dobben de Bruijnstraat"
ERROR dubbele spatie in straatnaam "Burgemeester Groenenbergstraat"
ERROR dubbele spatie in straatnaam "Wethouder M J van den Hatertstraat"
ERROR dubbele spatie in straatnaam "Provinciale Weg"
ERROR dubbele spatie in straatnaam "Burgemeester Wientjensstraat"
ERROR dubbele spatie in straatnaam "Oranje Gelderlandlaan"
ERROR back quote in straatnaam "`t Hoge Heem"
Kan iemand deze doorgeven aan de beheerder van BAG? Een van jullie zit
vast dichter bij het vuur.
De tien meest voorkomende straatnamen zijn:
Dorpsstraat
Kerkstraat
Hoofdstraat
Molenstraat
Schoolstraat
Nieuwstraat
Wilhelminastraat
Julianastraat
Hoofdweg
Stationsstraat
Ik zal eens kijken welke straatnamen in de aankomende spellingcontrole
nog op kunnen nemen
Aantal opmerkelijke straatnamen met karakters die nergens anders worden
gebruikt zijn:
Örehof
Önninkweg
Öldersweg
Salvador Dalístraat
Estelístraat
De Holtskòle
Bartòk
São Paulodreef
São Paulostraat
Ávilastraat
Nîmeslaan
Buñuellaan
Laan van Køge
Dvořákhof
Van deze laatste is naar mijn idee de ř een brug te ver. Over het
algemeen wordt een haček (behalve in het woord haček) in het Nederlands
weggelaten. Wat vinden jullie?
Groeten,
Pander
>
> Hartelijke groet,
>
> --Just
>
>
>
>
>
> _______________________________________________
> Talk-nl mailing list
> Tal...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
--
Stichting OpenTaal
http://opentaal.org
http://twitter.com/opentaal
Gert-Jan van der Weijden
En mooi dat de volledige naam er wordt gebruikt, en geen verminking waarbij het "Tsjechisch haakje" (haček) wordt weggelaten.
Strafpunten voor Zwijndrecht, dat botweg alle diakritische tekens in de naam van deze componist negeert.
Uit het feit dat de Dvorakstraat in Zwijndrecht bij de Mozartlaan in de buurt ligt concludeer ik maar even dat het daadwerkelijk om de componist Dvořák gaat, en niet om de Amerikaanse uitvinder van een toetenbordindeling August Dvorak.
(2 aardige details: 200 m verderop in Zwijndrecht ligt een straat met de naam "Kaartenmaker". En die Hoornse Dvořákhof heeft ook een eigenaardigheid: voor een deel is van de straat waarvan de ene zijde Dvořákhof heet, en de andere zijde Smetanahof. Wie verzint zoiets?)
Verder: ook de naam van de Tsjechoslowaakse voorman van de Praagse Lente Dubček op veel plaatsen ook verminkt tot "Dubcek". En componist Béla Bartók komt op alle mogelijke manier voor in de Nederlandse straatnamen. Met alleen een accent op de e van Bela, met 2 accenten, geheel zonder accenten, en zelfs -ongetwijfeld goedbedoeld- met een "accent de verkeerde kant uit".
Het geeft allemaal wel het belang aan van de flexibiliteit van geocoders en andere straatnaamzoekers. Het zou rottig zijn als de hulpdiensten de route naar de Dvořákhof niet weet te vinden omdat de brandweerman de "r-met-haček" niet op zijn navigatiesysteem kan intoetsen.
groet,
Gert-Jan van der Weijden (met streepje, puntjes op de ij etc.)
-----Oorspronkelijk bericht-----
Van: Pander OpenTaal [mailto:pan...@opentaal.org]
Verzonden: dinsdag 9 juni 2015 22:16
Aan: OpenStreetMap NL discussion list; du...@lists.osgeo.org; nlex...@googlegroups.com; OpenGeoGroep Mailinglist
Onderwerp: Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015
Colin Smale
De straat heet hoe de straat heet - spelfouten inbegrepen. De bron van de enige echte naamgeving is een gemeentelijk besluit. Dat wordt (hopelijk zonder fouten) overgenomen in de BAG. Ik weet niet waar degene kijkt die straatnaamborden bestelt, maar ook daar kan een foutje insluipen. En vervolgens kan de bordjesfabrikant ook een fout maken. Zeker als die gekke tekens niet makkelijk in te voeren zijn vanaf een normaal toetsenbord.
Het is dus zaak om te achterhalen waar in de keten de fout is ontstaan, en het probleem op de juiste plek op te lossen.
//colin
Pander OpenTaal
> Hi Just,
Pander :)
>
> Probleem BAG meldingen gaan naar het kadaster, die zijn echter wel
> gemeentelijk georienteerd. Zonder gemeente naam of code sturen ze een
> melding als onbestelbaar retour, niet vriendelijk maar uitzoeken is
> nachtwerk.
>
> Mvg
>
> Nick
Ik heb mijn script nu zeer generiek gemaakt en deze rapporteert nu voor
alle interessante kolommen in de BAG-export:
- TSV-bestand met histogram van waarden
- TSV-bestand histogram van gebruikte karakters
en het maakt een CSV-bestand met de desbetreffende regels waar een fout
in zit.
De fouten heb ik aan dit bericht toegevoegd. Het zijn fouten in 179
adressen die voorkomen uit maar 7 fouten in straatnamen. Wie kan dat
doorzetten?
De TSV-bestanden zijn interessant als je statistische gegevens over
Nederlandse adressen wil hebben en BAG-export op fouten wil controleren.
Hieronder staat voor een aantal bestanden de eerste en de laatste vijf
regels met korte toelichting:
Meeste adressen per provincie zijn in Zuid-Holland en de minste in
Flevoland:
histogram_values_provincie.tsv
1867916 Zuid-Holland
1479784 Noord-Holland
1218314 Noord-Brabant
1003293 Gelderland
614422 Utrecht
...
346361 Friesland
303551 Groningen
250258 Drenthe
221034 Zeeland
183197 Flevoland
Meeste en minste adressen betreft gemeentes zijn:
histogram_values_gemeente.tsv
473108 Amsterdam
352579 Rotterdam
281475 's-Gravenhage
164292 Utrecht
114006 Eindhoven
...
2700 Haarlemmerliede en Spaarnwoude
2118 Renswoude
1466 Schiermonnikoog
1189 Vlieland
671 Rozendaal
In de namen van gemeentes komen de volgende karakters veel en zeer
zelden voor:
histogram_chars_gemeente.tsv
654 e
317 n
276 r
248 a
202 l
...
2 .
2 '
1 ú
1 â
1 ,
Naast de gemeentes zijn er de woonplaatsen met aantal adressen:
histogram_values_woonplaats.tsv
473108 Amsterdam
318470 Rotterdam
281475 's-Gravenhage
145927 Utrecht
114006 Eindhoven
...
7 Ossenwaard
6 Breezanddijk
6 Idzega
5 Smallebrugge
5 Geelbroek
Ook deze hebben ongebruikelijke karakters:
histogram_chars_woonplaats.tsv
3597 e
1615 r
1590 n
1198 a
1190 o
...
4 û
2 2
1 1
1 é
1 ú
Als je de Postcodestaatsloterijwhatever belangrijk vindt denk maar eens
na of dit invloed heeft op jouw leven en of je moet verhuizen:
histogram_values_postcode.tsv
1192 3781PP
837 3896LD
821 1083HP
811 4325DM
792 6598LA
...
1 2743CH
1 7957ED
1 8064XM
1 3371SP
1 5091JK
De meeste postcodes bevatten een '1' en zeer zelden een 'U':
histogram_chars_postcode.tsv
304752 1
229836 2
212903 3
195599 5
177934 4
...
23 O
18 Q
7 Y
4 F
1 U
Meeste adressen hebben geen huisnummertoevoeging, maar als er die is, is
het meestal een '1' of '2' en zeer zelden lange toevoegingen, al kunnen
die wel complex zijn:
histogram_values_huisnummertoevoeging.tsv
8062787
58224 1
52691 2
41433 H
39908 3
...
1 R348
1 A87
1 3329
1 k03I
1 18b
De meeste huisnummers zijn een '1', daarna een '2' en ga maar door. De
meest zeldzame zijn vrij lang. Die mensen kun je post sturen zonder
woonplaats, postcode of straatnaam. Dat laatste zou je ook over zeldzame
huisnummertoevoegingen kunnen zeggen:
histogram_values_huisnummer.tsv
245526 1
229318 2
197155 3
196194 4
189590 5
1 5269
1 4090
1 16524
1 5841
1 23010
Ik weet niet exact wat dit is maar er zijn 26294 nevenadressen in Nederland:
histogram_values_nevenadres.tsv
8599746 f
26294 t
Weet iemand wat dit voor informatie is? VBO=? STA=staplaats? LIG=ligplaats?
histogram_values_object_type.tsv
8599234 VBO
14963 STA
11843 LIG
De gewone man woont in de Dorpsstraat. Zou er iemand wonen in
Metrostation Wibautstraat? Is er een boerderij op de Weelhoekweg?
histogram_values_openbareruimte.tsv
27335 Dorpsstraat
22191 Kerkstraat
17289 Hoofdstraat
15106 Molenstraat
14611 Schoolstraat
...
1 Waldfeuchterweg
1 Metrostation Wibautstraat
1 Hilweg
1 Herschelpad
1 Weelhoekweg
Straatnamen kunnen dus ook ongebruikelijke karakters bevatten:
histogram_chars_openbareruimte.tsv
232432 e
183629 a
136113 r
124896 t
110114 n
...
1 ,
1 î
1 Á
1 ñ
1 ř
Afijn, een hele berg data ter lering en vermaak. Stichting OpenTaal kan
aan de hand van deze statistieken beter beslissen welke namen, die we
via meerdere wegen bijgedragen gekregen hebben, op te nemen in de
Nederlandse spellingcontrole.
Wie is dé persoon die met de export van BAG regulier aan de slag gaat
voor OSM en andere open toepassingen? Graag zou ik mijn script willen
doneren die naast TSV en CSV ook kan rapporteren in HTML en XML. Op die
manier orden deze lijsten en statistische gegevens makkelijker ontsloten
aan iedereen die met adresinformatie te maken heeft.
Groeten,
Pander
Sebastiaan Couwenberg
> adressen die voorkomen uit maar 7 fouten in straatnamen. Wie kan dat
> doorzetten?
Je bent zelf de meeste aangewezen persoon om deze fouten terug te melden.
https://www.kadaster.nl/web/formulier/BAG-formulieren/BAG-terugmeldingsformulier.htm
Lees ook het BAG processenhandboek waarin de verschillende velden
beschreven zijn, zo kan je duidelijk geformuleerde terugmeldingen doen.
http://www.kadaster.nl/web/artikel/download/BAG-processenhandboek-2013-1.htm
Mvg,
Bas
Pander OpenTaal
>
>
>
>
> De straat heet hoe de straat heet - spelfouten inbegrepen. De bron van
> de enige echte naamgeving is een gemeentelijk besluit. Dat wordt
> (hopelijk zonder fouten) overgenomen in de BAG. Ik weet niet waar degene
> kijkt die straatnaamborden bestelt, maar ook daar kan een foutje
> insluipen. En vervolgens kan de bordjesfabrikant ook een fout maken.
> Zeker als die gekke tekens niet makkelijk in te voeren zijn vanaf een
> normaal toetsenbord.
>
> Het is dus zaak om te achterhalen waar in de keten de fout is ontstaan,
> en het probleem op de juiste plek op te lossen.
Dit is ook een van de voordelen van open data, dat er meer mensen mee
kunnen helpen de kwaliteit te verbeteren.
Hoeveel fabrikanten van straatnaambordjes zijn er eigenlijk in
Nederland? Vanuit Stichting OpenTaal was ik al op zoek naar fabrikanten
van software voor borden voor wegwerkzaamheden maar dat liep op dood spoor.
Idee om met klein groepje vanuit OSM een overzicht hiervan te maken? Als
het enkele zijn zou dat ook wel een bezoekje waard zijn. Wie weet hebben
zij nog interesse in een webservice of procedureel advies die potentiële
fouten in straatnamen aangeeft.
Wat betreft het gemakkelijk invoeren van ongebruikelijke tekens op Linux
voor OSM-doeleinden, zie https://www.createspace.com/3758226
-
Gert-Jan, heb je (wij) interesse in een overzicht van straatnamen die
alleen in diakritisch teken verschillen? Kan eventueel einde van de naam
als straat, hof, laan, plein, etc. er eerst afgehaald worden. Vallen ook
die accenten die de verkeerde kant op staan eruit.
Speaking of which, is er ergens een overzicht van meest gangbare eindes
van straatnamen?
Wat betreft veiligheidsoverwegingen en gebruiksgemak zou ik persoonlijk
de haček afraden op een r. Voor namen van mensen uit Servië wordt deze
in kranten al nooit gebruikt (zie Milosovic versus Milosovič) maar weet
men meestal wel hoe het uit te spreken. Dus č, š en ž zijn goed om te
gebruiken.
Betreft de Tsjechische ř denk ik dat een op de 100.000 mensen in
Nederland deze niet eens correct kan uitspreken en dat is niet handig
als je hulpdiensten opbelt. Over de ř, ň, ě, ů en ł heb ik dan ook mijn
twijfels om die te gebruiken.
>> <mailto:du...@lists.osgeo.org>; nlex...@googlegroups.com
>> <mailto:nlex...@googlegroups.com>; OpenGeoGroep Mailinglist
>>> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-nl
>>
>>
>> --
>> Stichting OpenTaal
>> http://opentaal.org
>> http://twitter.com/opentaal
>>
>> _______________________________________________
>> Talk-nl mailing list
>> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-nl
>>
>>
>> _______________________________________________
>> Talk-nl mailing list
>> Tal...@openstreetmap.org <mailto:Tal...@openstreetmap.org>
Maarten Deen
> Hoeveel fabrikanten van straatnaambordjes zijn er eigenlijk in
> Nederland? Vanuit Stichting OpenTaal was ik al op zoek naar fabrikanten
> van software voor borden voor wegwerkzaamheden maar dat liep op dood
> spoor.
Ik ken AGMI in Tegelen: http://www.agmi.nl/
> Idee om met klein groepje vanuit OSM een overzicht hiervan te maken?
> Als
> het enkele zijn zou dat ook wel een bezoekje waard zijn. Wie weet
> hebben
> zij nog interesse in een webservice of procedureel advies die
> potentiële
> fouten in straatnamen aangeeft.
Interessant is ook wie de database voor de onderschriften bij
straatnamen beheert.
Maarten
St Niklaas
Onderstaand het mail adres van de vereniging van borden fabrikanten in Nederland.
in...@vnvf.nl
Ik ben benieuwd, mijn vorige poging om het digitale bordenboek voor OSM binnen te halen strandde op u kunt het kopen, zonder een afspraak aangaande de rechten van de plaatjes.
Hendrikklaas
Voor een bezichtiging kun je beter een fabrikant uit de onderstaande lijst benaderen;
http://www.vnvf.nl/links/
succes
Just van den Broecke
Er was nog een antwoord van Raymond (zie onder). Die was vanwege, mea
culpa, aanvankelijke cross-post niet naar alle fora. Maar dit antwoord
zag ik al voorbij komen. Je moet dus aan begin van BAG-keten zitten.
Voor Kadaster en NLExtract is het: Garbage In/Garbage Out :-(.
Hoewel NLExtract nog wel de ergste mistypo's (ik dacht backslashes, die
tot "escape sequences" kunnen leiden en null chars eruit filtert).
groet,
Just
-------- Forwarded Message --------
Subject: Re: [Dutch] [Open Geo Groep] Re: [OSM-talk-nl] BAG en Top10NL
PostGIS dumps van april 2015
Date: Wed, 10 Jun 2015 08:47:41 +0200
From: Raymond Nijssen <r.ni...@terglobo.nl>
Organization: Terglobo
To: du...@lists.osgeo.org <du...@lists.osgeo.org>
Beste Pander,
De BAG wordt beheerd door alle afzonderlijke gemeenten. Het kadaster
beheert en ontsluit de totale dataset maar verbetert geen fouten.
Fouten melden kan hier:
https://www.kadaster.nl/web/formulier/BAG-formulieren/BAG-terugmeldingsformulier.htm
Wanneer je weet in welke gemeente de openbare ruimte ligt kun je ook
direct direct contact opnemen. Mijn ervaring is dat dat beter werkt(e).
Groet,
Raymond
>> _______________________________________________
>> Talk-nl mailing list
>> Tal...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-nl
>
>
--
Terglobo
Ampèrestraat 110
5223 CT 's-Hertogenbosch
06-25314983
_______________________________________________
Dutch mailing list
Du...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/dutch
Ster, Eric van der (CIV)
Wat wellicht ook kan helpen:
Publicatieplicht verkeersbesluiten:
(loket met publicaties kan ik zo even niet zo snel vinden). Middels verkeersbesluiten kun je zien wat de wegbeheerder aan verkeersmaatregelen neemt.
RWS beheert het borden bestand met bewegwijzering. Wordt nog opengesteld voor hergebruik.
Eric van der Ster
Van: St Niklaas [mailto:st.ni...@live.nl]
Verzonden: woensdag 10 juni 2015 17:23
Aan: OpenStreetMap NL discussion list
Onderwerp: Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015
Beste Maarten Deen,
Just van den Broecke
Graag dit soort meldingen naar alleen de NLExtract lijst. Dit is dan de
laatste cross-post...sorry mensen.
In de laatste (GitHub) versie van NLExtract is rekening gehouden met
MultiPolygonen, zie issue
https://github.com/opengeogroep/NLExtract/issues/138.
Deze worden in de juni-2015-versie van BRT in ieder geval ook door
Kadaster geleverd en door NLExtract goed ingelezen. In jouw geval lijkt
er egens een mismatch tussen jouw NLExtract versie, je database en de
BRT brondata.
De dump van bijv juni 2015
http://data.nlextract.nl/top10nl/postgis/jun2015/ bevat deze
MultiPolygonen.
Groet,
Just
On 28-07-15 16:35, Elmer Cladder - Geodan wrote:
> Ha Just,
>
> Ik liep tijdens het inlezen van BRT april 2015 na het splitten tegen het
> volgende aan:
>
> Warning 1: Geometry to be inserted is of type Multi Polygon, whereas
> the layer geometry type is Polygon.
> Insertion is likely to fail
> ERROR 1: INSERT command for new feature failed.
> ERROR: Geometry type (MultiPolygon) does not match column type
> (Polygon)
> Command: INSERT INTO "functioneelgebied_vlak" ("wkb_geometry" ,
> "fid", "identificatie", "objectbegintijd", "versiebegintijd",
> "typefunctioneelgebied",
> "brontype", "bronbeschrijving", "bronactualiteit",
> "bronnauwkeurigheid", "dimensie", "visualisatiecode", "tdncode")
> VALUES ('010600002040710000020000
> 00010300000001000000290000003BDF4F8DACEF0E415A643BDFD2ED2141DD2406811CEE0E4152B81E05D1ED214125068195E7ED0E4191ED7CFFC2ED2141FED478E9A4ED0E4191ED7CFFC2
> ED21414A0C022B73ED0E413F355E3AD0ED2141643BDF4FB4E90E41BA490C42CCED2141666666667FE90E4100000080BEED214185EB51B83CE90E41FA7E6A3CBEED2141A01A2FDD08E90E41
> AE47E1BACBED21416ABC749378E50E419EEFA706C8ED214185EB51B844E50E416891EDBCB9ED21415EBA490C02E50E41F4FDD478B9ED2141A245B6F3C9E40E411D5A643BC7ED2141378941
> 6030E30E419A9999D9C4ED21416DE7FBA9C8E20E41E5D0225BB7ED2141B29DEFA7DAE20E41BC7493D8CFEC2141B07268910FE30E410AD7A3F0C3EC2141273108AC35E30E41F2D24DE2B9EC
> 2141FA7E6ABC1CE70E417D3F351EBEEC2141E17A14AE1BE70E41C1CAA1C5AEEC2141CFF753E355E70E41B0726811ABEC2141F853E3A563E70E41A245B6F3A8EC21418716D9CE8AE70E4106
> 819503A1EC2141C976BE9F99E70E41D34D629076EB21410C022B87DEE80E41E7FBA9F178EB21410C022B87DEE80E410E2DB25D65EB214125068195E9EC0E412B87169969EB214148E17A14
> 29ED0E41E7FBA9F178EB2141DD2406811EED0E41643BDF4FDAEB2141295C8FC2ECEC0E41A4703D8AE7EB214125068195E9EC0E416891EDBCF8EB2141F6285C8F1FED0E418716D90E03EC21
> 41EE7C3F3519ED0E41295C8F826AEC21411D5A643BE3EC0E41D578E92676EC214100000000DFEC0E411F85EBD186EC2141D122DBF914ED0E4152B81E8593EC2141E17A14AE0FED0E4191ED
> 7CFFC4EC21418195438BBEEF0E412731082CC8EC2141D9CEF75315F00E4177BE9F9ADDEC2141A8C64B3701F00E41FA7E6A3CBEED21413BDF4F8DACEF0E415A643BDFD2ED21410103000000
> 01000000050000000E2DB29DA1EC0E41508D97EE14EB2141F2D24D629DEC0E410E2DB29D45EB21415EBA490C75EB0E410C022B0744EB21416210583978EB0E41C3F5289C13EB21410E2DB2
> 9DA1EC0E41508D97EE14EB2141'::GEOMETRY, 100010856,
> 'NL.TOP10NL.100010856', '2008-11-24T00:00:00.000',
> '2015-03-28T20:25:53.000', 'gaswinning', 'luchtfo
> to', 'Een orthogerectificeerde fotografische opname van een deel van
> het aardoppervlak. Gemaakt vanuit een vliegtuig.', '2014-01-01',
> 0.1, '2D', 19130
> , 999) RETURNING "ogc_fid"
> ERROR 1: Terminating translation prematurely after failed
> translation of layer FunctioneelGebied_Vlak (use -skipfailures to
> skip errors)
>
>
> Heb jij dit ook gehad en zo ja, hoe heb je dit opgelost?
>
> Groet, Elmer
Raymond Nijssen
Did you add the extension Postgis to your database, for handeling
spatial data types (geometry)?
Hope this helps,
Raymond
On 10-02-17 10:42, Fatemeh Mahmoudi wrote:
> Dear all,
>
> I have a problem with restroing bag data in Postgres through pgAdmin.
> But The pandactuell which has the geospatila values is not loading with
> following error!
>
>
>
> (pg_restore: creating TABLE "bagactueel.pand"
> pg_restore: [archiver (db)] Error from TOC entry 380; 1259 554851963
> TABLE pand kademo
> pg_restore: [archiver (db)] could not execute query: ERROR: type
> "public.geometry" does not exist
> LINE 15: geovlak public.geometry,
> ^
> Command was: CREATE TABLE pand (
> gid integer NOT NULL,
> identificatie numeric(16,0),
> aanduidingrecordinactief boolean,
> aan...
> pg_restore: [archiver (db)] could not execute query: ERROR: relation
> "pand" does not exist
> Command was: ALTER TABLE pand OWNER TO kademo;)
>
> I had done this before and it worked but now does not!
>
> does anyone know about it?
>
> Regards,
> Fatemeh
>
>
> On Sunday, April 26, 2015 at 11:56:13 PM UTC+2, Just van den Broecke wrote:
>