Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp Just van den Broecke @Nexus10
Als ik de foutmelding zie vermoed ik dat het 'protocol' object geen 'request' 
veld mag bevatten. Ook zijn er recent wat naamswijzigingen in laagnamen voor 
best. grenzen geweest. Check via GetCapabilities. WFS 1.1.0 moet werken. 
Gebruik ik ook in mijn Heron apps op basis OpenLayers, bijv: 

   bag_panden_wfs: [OpenLayers.Layer.Vector, BAG - Panden (WFS), {
maxResolution: 0.84,
strategies: [new OpenLayers.Strategy.BBOX()],
visibility: false,
styleMap: new OpenLayers.StyleMap(
{'strokeColor': '#22', 'fillColor': '#ee', 
graphicZIndex: 1, fillOpacity: 0.8}),
protocol: new OpenLayers.Protocol.WFS({
url: Heron.PDOK.urls.BAGVIEWER,
featureType: pand,
featureNS: http://bagviewer.geonovum.nl;,
geometryName: 'geometrie'
})
}],

Let vooral op 'protocol' object en gebruik namespace, rest syntax is 
Heron-specifiek http://heron-mc.org.
Just van den Broecke @Nexus10

Sebastiaan Couwenberg sebas...@xs4all.nl wrote:

On 10/15/2013 11:49 PM, nouwsfam wrote:
 Is er iemand die mij een voorbeeld kan geven van hoe ik de
 gemeentegrenzen_2012 uit de WFS service van
 geodata.nationaalgeoregister.nl kan krijgen?

In mijn OpenLayers site gebruik ik jQuery om m.b.v. de GetCapabilities
requests dynamisch WFS layers toe te voegen.

Voor de bestuurlijke grenzen WFS word uiteindelijk een Vector Layer als
deze gegenereerd:

wfs_layers[key][i] = new OpenLayers.Layer.Vector(layer_name, {
strategies: [new OpenLayers.Strategy.BBOX()],
protocol: new OpenLayers.Protocol.WFS({
version: 1.0.0,
srsName: 'EPSG:28992',
url:
'http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs',
featurePrefix: 'bestuurlijkegrenzen',
featureType: 'gemeenten_2012',
featureNS: 'http://bestuurlijkegrenzen.geonovum.nl',
geometryName: 'geom',
}),
projection: new OpenLayers.Projection('EPSG:28992'),
styleMap: wfs_stylemap[key],
});
map.addLayer(wfs_layers[key][i]);

Het verschil met jou versie is het specificeren van andere geometryName,
en de featureType en featurePrefix worden afzonderlijk gespecifieerd,
evenals het gebruik van versie 1.0.0 van het WFS protocol.

Het is mij niet helemaal duidelijk wat er mis is met jouw Vector Layer.
Ik vermoed extra vereisten in versie 1.1.0 WFS requests.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp Gert-Jan van der Weijden
Los van de techniek: 

De grenzen die van 2012, binnenkort (maar dat is voor de beheerclub van 
geodata.nationaalgeoregister.nl een rekbaar begrip) moeten de grenzen zoals die 
per 1-1-2013 gelden (o.a. Goeree-Overflakkee tegenwoordig 1 gemeente) als 
WMS/WFS services beschikbaar komen. Daarbij gaan de laagnamen ook op de helling.

 

Groet, 

 

Gert-Jan

 

Van: nouwsfam [mailto:nouws...@xs4all.nl] 
Verzonden: dinsdag 15 oktober 2013 23:49
Aan: talk-nl@openstreetmap.org
Onderwerp: [OSM-talk-nl] nationaalgeoregister WFS service query

 

Is er iemand die mij een voorbeeld kan geven van hoe ik de gemeentegrenzen_2012 
uit de WFS service van geodata.nationaalgeoregister.nl kan krijgen? Ik krijg 
foutmeldingen van de server, die ik niet snap. Ik kan nergens documentatie of 
voorbeelden vinden.

Ik heb het onderstaande (onder meer) uitgeprobeerd:

var gemeenteGrenzenLayer = new OpenLayers.Layer.Vector(
Gemeentegrenzen, 
{
strategies: [new OpenLayers.Strategy.BBOX()],
styleMap : gemeenteGrenzenStyleMap, 
protocol: new OpenLayers.Protocol.WFS({
version: 1.1.0,
url:  
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;,
request: GetFeature,
featureType: bestuurlijkegrenzen:gemeenten_2012,
srsName: EPSG:28992,
featureNS: http://bestuurlijkegrenzen.geonovum.nl;,
geometryName: 'geometrie'

})
}
);
map.addLayer (gemeenteGrenzenLayer);

 

Het werkt dus niet. De foutmelding is ows:Exception 
exceptionCode=MissingParameterValue locator=request

Dank voor jullie hulp!

PS: de WMS server heb ik wel aan de praat, maar de png's zijn lelijk. Ik kan de 
data ook uit OSM krijgen, maar dit is 6 MB. Daarom wil ik de WFS service 
uitproberen.

 

 

 

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp nouwsfam


Ik ben niet zo goed thuis in GetCapabilities, excuses. Ik vind het knap
hoe jullie daaruit kunnen halen welke argumenten je mee moet geven aan
een WFS query. Ik zie het niet. 

Hoe dan ook, het werkt nog steeds niet. 

Een GET via de url werkt wel: 

http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?request=GetFeaturetypeName=gemeenten_2012


maar doe ik het via OpenLayers, dan krijg ik nog steeds foutmeldingen,
welke argumenten ik ook meegeef. De foutmelding van JavaScript is 

NetworkError: 500 Internal Server Error -
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs; 

en de foutmelding van de WFS server is nu 

Reload the page to get source for:
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;

Het kan dus zijn dat het probleem in een andere hoek zit dan de WFS
query. Misschien een proxy? Geen idee.
Henk

Just van den Broecke @Nexus10 schreef op 2013-10-16 08:02: 

 Als ik de foutmelding zie vermoed ik dat het 'protocol' object geen 'request' 
 veld mag bevatten. Ook zijn er recent wat naamswijzigingen in laagnamen voor 
 best. grenzen geweest. Check via GetCapabilities. WFS 1.1.0 moet werken. 
 Gebruik ik ook in mijn Heron apps op basis OpenLayers, bijv: 
 
 bag_panden_wfs: [OpenLayers.Layer.Vector, BAG - Panden (WFS), {
 maxResolution: 0.84,
 strategies: [new OpenLayers.Strategy.BBOX()],
 visibility: false,
 styleMap: new OpenLayers.StyleMap(
 {'strokeColor': '#22', 'fillColor': '#ee', graphicZIndex: 1, 
 fillOpacity: 0.8}),
 protocol: new OpenLayers.Protocol.WFS({
 url: Heron.PDOK.urls.BAGVIEWER,
 featureType: pand,
 featureNS: http://bagviewer.geonovum.nl [1],
 geometryName: 'geometrie'
 })
 }],
 
 Let vooral op 'protocol' object en gebruik namespace, rest syntax is 
 Heron-specifiek http://heron-mc.org [2].
 Just van den Broecke @Nexus10
 
 Sebastiaan Couwenberg sebas...@xs4all.nl wrote:
 On 10/15/2013 11:49 PM, nouwsfam wrote: Is er iemand die mij een voorbeeld 
 kan geven van hoe ik de gemeentegrenzen_2012 uit de WFS service van 
 geodata.nationaalgeoregister.nl kan krijgen? In mijn OpenLayers site gebruik 
 ik jQuery om m.b.v. de GetCapabilities requests dynamisch WFS layers toe te 
 voegen. Voor de bestuurlijke grenzen WFS word uiteindelijk een Vector Layer 
 als deze gegenereerd: wfs_layers[key][i] = new 
 OpenLayers.Layer.Vector(layer_name, { strategies: [new 
 OpenLayers.Strategy.BBOX()], protocol: new OpenLayers.Protocol.WFS({ version: 
 1.0.0, srsName: 'EPSG:28992', url: 
 'http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs [3]', 
 featurePrefix: 'bestuurlijkegrenzen', featureType: 'gemeenten_2012', 
 featureNS: 'http://bestuurlijkegrenzen.geonovum.nl [4]', geometryName: 
 'geom', }), projection: new OpenLayers.Projection('EPSG:28992'), styleMap: 
 wfs_stylemap[key], }); map.addLayer(wfs_layers[key][i]); Het verschil met jou 
 versie is het specificeren van ande!
 re
geometryName, en de featureType en featurePrefix worden afzonderlijk 
gespecifieerd, evenals het gebruik van versie 1.0.0 van het WFS protocol. Het 
is mij niet helemaal duidelijk wat er mis is met jouw Vector Layer. Ik vermoed 
extra vereisten in versie 1.1.0 WFS requests. Mvg, Bas -- GnuPG: 0xE88D4AF1 
(new) / 0x77A975AD (old) ___ 
Talk-nl mailing list Talk-nl@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-nl [5]

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl [5]



Links:
--
[1] http://bagviewer.geonovum.nl
[2] http://heron-mc.org
[3] http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs
[4] http://bestuurlijkegrenzen.geonovum.nl
[5] https://lists.openstreetmap.org/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp Christ van Willegen
2013/10/16 nouwsfam nouws...@xs4all.nl:

 NetworkError: 500 Internal Server Error -
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;

 en de foutmelding van de WFS server is nu

 Reload the page to get source for:
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;

Dat is niet de foutmelding van de WFS server, maar FireBug toont daar
deze tekst...

Die 'internal server error' is het probleem, maar dan krijg je ook,
over het algemeen, _geen_ data terug...

Christ van Willegen
-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


[OSM-talk-nl] topologievraag

2013-10-16 Berichten over hetzelfde onderwerp Geert Ribbers
Het valt me op dat routeren in Mapsource / Basecamp in een OSM kaart vaak
niet goed gaat als een fietspad direct naast een weg gelegen is.
Meestal is dit een zandweg met een los fietspad ernaast, wat ook uitgevoerd
had kunnen zijn als highway=track met cycleway=track.
 
Wil je nou in Mapsource of Basecamp een route dwars over deze combinatie
leggen, dan weigeren beide programma's er dwars overheen te gaan.
Meestal wordt er een chicane gemaakt naar de overkant.
Als je de verbindingen controleert in OSM dan geeft hij aan dat de boel
keurig aan elkaar zit.
 
Voorbeelden die ik net weer tegenkom:
http://www.openstreetmap.org/#map=19/52.09971/6.43951
http://www.openstreetmap.org/#map=19/52.10107/6.44196
http://www.openstreetmap.org/#map=19/52.10247/6.44121
http://www.openstreetmap.org/#map=19/52.15114/6.58768
 
Dezelfde situatie (lijkt mij tenminste) waar het wel goed gaat:
http://www.openstreetmap.org/#map=19/52.10001/6.45054
 
Wat is nou het verschil, waarom gaat het zo vaak mis terwijl toch de nodes
keurig gedeeld worden.
En gaat het soms dan toch ook wel weer goed.

Groeten, Geert Ribbers




___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] topologievraag

2013-10-16 Berichten over hetzelfde onderwerp Minko
Welk kaart en welke instellingen gebruik je voor het routeren?
De openfietsmap heeft geen problemen met deze wegen, want ze zijn in jouw 
voorbeelden als aparte ways ingetekend. Misschien staan je 
routeringsinstellingen verkeerd?
Zie http://www.openfietsmap.nl/tips-tricks/mapsource_nl en 
http://www.openfietsmap.nl/tips-tricks/basecamp-nl

 Het valt me op dat routeren in Mapsource / Basecamp in een OSM kaart
 vaak
 niet goed gaat als een fietspad direct naast een weg gelegen is.
 Meestal is dit een zandweg met een los fietspad ernaast, wat ook
 uitgevoerd
 had kunnen zijn als highway=track met cycleway=track.


Ik ben niet zo gecharmeerd van die combinatie. Het is beter deze twee als 
aparte ways in te tekenen. Vaak gaat het om wegen met verschillende 
eigenschappen, bv het fietspad is geasfalteerd en de track is een zandweg. Met 
onverhard vermijden ingeschakeld vermijdt je dan ook dat fietspad omdat de 
hoofdrijbaan een track is.
Ik zou cycleway=track hooguit gebruiken op geasfalteerde (hoofd)wegen waarbij 
het fietspad bv gescheiden van de rijbaan is met een betonnenrandje o.i.d. en 
niet voor zandpaden. 



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp Just van den Broecke

Ok, welkom in de wondere wereld van WFS en OGC-protocollen :-).
Het voordeel (boven een expliciete API zoals OSM XAPI) is dat je maar 1 
protocol spec (WFS) hoeft te kennen. Op grond van een URL zoals 
geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs moet je alle 
metadata (types etc) kunnen opvragen. Nadeel is dat WFS 
onhandig/verbose/redundant in elkaar zit. Meestal 2 stappen om uit te 
vinden welke parameters je nodig hebt:


GetCapabilities:
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFSrequest=GetCapabilitiesversion=1.1.0
DescribeFeatureType:
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFSrequest=DescribeFeatureTypeversion=1.1.0

Vooral uit de laatste haal je (onderaan) dat de laagnaam 
'gemeenten_2012' en het geometrie-veld 'geom' moet zijn (bij jou stond 
'geometrie').


Op grond daarvan heb ik net geprobeerd een OL laag toe te voegen in een 
viewer waar ik net aan werk (http://kadviewer.kademo.nl) en zie dat dit 
werkt:


new OpenLayers.Layer.Vector(Bestuurlijke Grenzen - Gemeenten (WFS), {
strategies: [new OpenLayers.Strategy.BBOX()],
visibility: false,
styleMap: new OpenLayers.StyleMap(
{'strokeColor': '#22', 'fillColor': '#ee', 
graphicZIndex: 1, fillOpacity: 0.6}),

protocol: new OpenLayers.Protocol.WFS({
version: '1.1.0',
outputFormat: 'GML2',
srsName: 'EPSG:28992',
url: 
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?,

featureType: gemeenten_2012,
featureNS: http://bestuurlijkegrenzen.geonovum.nl;,
geometryName: 'geom'
})
})

Gotcha: er zit een al 2 jaar bekend probleem in PDOK (GeoServer) WFS bij 
gebruik van WFS 1.1.0: je krijgt standaard GML 3.1.1 output terug, maar 
daarin zitten 'null' namespaces. Dat weten ze daar ook al 2 jaar, maar 
heeft blijkbaar geen prio. Daarom als je outputFormat='GML2' opgeeft, 
gaat het goed. Je kunt ook version: 1.0.0 (default) opgeven dan krijg je 
standaard GML2 terug. Je kunt zelfs outputFormat=json of zelfs SHAPE-ZIP 
opvragen...Wie volgt dit nog ;-)?


Goed, ja ik ben deze dagen, vaak knarsetandend, met WFS bezig, dus 
leuk dit voorbij te zien komen. Overigens kan de 500 error goed met je 
proxy-instelling, nodig bij OpenLayers+WFS, te maken hebben...


groet!

Just



On 16-10-13 09:20, Christ van Willegen wrote:

2013/10/16 nouwsfam nouws...@xs4all.nl:


NetworkError: 500 Internal Server Error -
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;

en de foutmelding van de WFS server is nu

Reload the page to get source for:
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;


Dat is niet de foutmelding van de WFS server, maar FireBug toont daar
deze tekst...

Die 'internal server error' is het probleem, maar dan krijg je ook,
over het algemeen, _geen_ data terug...

Christ van Willegen




--
kind regards / met vriendelijke groet,

--Just

Just van den Broecke  j...@justobjects.nl
Just Objects B.V. tel +31 65 4268627 Skype: justb4
The Netherlands   http://www.justobjects.nl






___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] topologievraag

2013-10-16 Berichten over hetzelfde onderwerp Geert Ribbers
Het gaat goed op Open MTB Map en fout op zowel GR als OFM (die ik eigenlijk 
altijd gebruik).
En op zowel instelling kortste afstand als snelste tijd. 
En ook de schuif Wegselectie maakt niets uit (Mapsource).
En het gaat een keer fout bij een fietsroute over het fietspad, maar in het 
voorbeeld dat het goed gaat, gaat dezelfde fietsroute over het fietspad. Dus 
ook dat maakt niet uit.

Maar wel zie ik nu dat het bij Voertuig Voetganger overal goed gaat. Daar had 
ik overheen gekeken blijkbaar.
Daarmee is mijn probleem dus opgelost. 
Bedankt.

Al kan ik dan nog niet begrijpen waarom dat zo is.
In het voorbeeld dat het wel goed gaat bij voertuig fiets komt er een track met 
grade5 uit op de combinatie fietspad / zandweg.
Bij de voorbeelden dat het niet goed gaat bij voertuig fiets komt er een pad op 
uit.
Dus het verschil hier is track / pad.
Als het correct topologisch aan elkaar zit, zowel het fietspad als de weg 
onverhard zijn, waarom zou een fiets dan niet dwars over die combinatie geleid 
worden.
Het is echt een hele vreemde lange chicane die gemaakt wordt. Een enorme omweg, 
die kan niemand ooit bedoelen.

Maar goed: kennelijk kun je bij een ATB en gewone fiets beter niet kiezen voor 
fiets maar voor voetganger.
In een gebied met veel onverharde weggetjes / paden. Als je het maar weet.

Wat cycleway track betreft: ja, als er verschillen in eigenschappen zijn die 
aangegeven moeten worden gaat dat niet werken.
Dat is duidelijk.
Zijn die verschillen er niet, dan wordt het er wel simpeler van (en keurig 
aangegeven / aan te geven in de stijl evengoed, zie OFM).

Met vriendelijke groet,
Geert Ribbers

-Oorspronkelijk bericht-
Van: Minko [mailto:ligfiet...@online.nl] 
Verzonden: woensdag 16 oktober 2013 11:03
Aan: ge...@groothagenbeek.nl; OpenStreetMap NL discussion list
Onderwerp: Re: [OSM-talk-nl] topologievraag

Welk kaart en welke instellingen gebruik je voor het routeren?
De openfietsmap heeft geen problemen met deze wegen, want ze zijn in jouw 
voorbeelden als aparte ways ingetekend. Misschien staan je 
routeringsinstellingen verkeerd?
Zie http://www.openfietsmap.nl/tips-tricks/mapsource_nl en 
http://www.openfietsmap.nl/tips-tricks/basecamp-nl

 Het valt me op dat routeren in Mapsource / Basecamp in een OSM kaart 
 vaak niet goed gaat als een fietspad direct naast een weg gelegen is.
 Meestal is dit een zandweg met een los fietspad ernaast, wat ook 
 uitgevoerd had kunnen zijn als highway=track met cycleway=track.


Ik ben niet zo gecharmeerd van die combinatie. Het is beter deze twee als 
aparte ways in te tekenen. Vaak gaat het om wegen met verschillende 
eigenschappen, bv het fietspad is geasfalteerd en de track is een zandweg. Met 
onverhard vermijden ingeschakeld vermijdt je dan ook dat fietspad omdat de 
hoofdrijbaan een track is.
Ik zou cycleway=track hooguit gebruiken op geasfalteerde (hoofd)wegen waarbij 
het fietspad bv gescheiden van de rijbaan is met een betonnenrandje o.i.d. en 
niet voor zandpaden. 




___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp Gertjan Idema
Na wat puzzelen, heb ik het voor elkaar.
In de bijlage een html bestand dat drie open layers lagen produceert:
- Osm mapnik als achtergrond.
- Gemeentegrenzen (van
http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs)
- Woonplaatsgrenzen (van
http://geodata.nationaalgeoregister.nl/bagviewer/wfs)

Opvallend is, dat de bagviewer laag werkt zonder de outputFormat: 'GML2'
toevoeging.

Verdere voorwaarde is wel dat je de proxy-host goed geconfigureerd hebt.
Zie hiervoor:
http://www.techrepublic.com/blog/diy-it-guy/diy-enable-cgi-on-your-apache-server/

Het proxy.cgi script vind je hier:
http://trac.osgeo.org/openlayers/browser/trunk/openlayers/examples/proxy.cgi?format=txt
Dit script moet je een klein beetje aan passen, door op regel 18 bij
allowedHosts 'geodata.nationaalgeoregister.nl' toe te voegen.
Als je dat vergeet, krijg je een 'bad gateway' foutmelding.

Houdt er wel rekening dat het even kan duren voor de data geladen is.
Met name de woonplaats grenzen.
Ook vermoed ik, dat door het gebruik van de proxy-host, alle data via
jouw server naar de client gaat. Als je een beperkt aantal GB per maand
hebt bij je provider, kan dat dus consequenties hebben.

Groeten, Gertjan 


On Wed, 2013-10-16 at 12:08 +0200, Just van den Broecke wrote:

 Ok, welkom in de wondere wereld van WFS en OGC-protocollen :-).
 Het voordeel (boven een expliciete API zoals OSM XAPI) is dat je maar 1 
 protocol spec (WFS) hoeft te kennen. Op grond van een URL zoals 
 geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs moet je alle 
 metadata (types etc) kunnen opvragen. Nadeel is dat WFS 
 onhandig/verbose/redundant in elkaar zit. Meestal 2 stappen om uit te 
 vinden welke parameters je nodig hebt:
 
 GetCapabilities:
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFSrequest=GetCapabilitiesversion=1.1.0
 DescribeFeatureType:
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFSrequest=DescribeFeatureTypeversion=1.1.0
 
 Vooral uit de laatste haal je (onderaan) dat de laagnaam 
 'gemeenten_2012' en het geometrie-veld 'geom' moet zijn (bij jou stond 
 'geometrie').
 
 Op grond daarvan heb ik net geprobeerd een OL laag toe te voegen in een 
 viewer waar ik net aan werk (http://kadviewer.kademo.nl) en zie dat dit 
 werkt:
 
  new OpenLayers.Layer.Vector(Bestuurlijke Grenzen - Gemeenten (WFS), {
  strategies: [new OpenLayers.Strategy.BBOX()],
  visibility: false,
  styleMap: new OpenLayers.StyleMap(
  {'strokeColor': '#22', 'fillColor': '#ee', 
 graphicZIndex: 1, fillOpacity: 0.6}),
  protocol: new OpenLayers.Protocol.WFS({
  version: '1.1.0',
  outputFormat: 'GML2',
  srsName: 'EPSG:28992',
  url: 
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?,
  featureType: gemeenten_2012,
  featureNS: http://bestuurlijkegrenzen.geonovum.nl;,
  geometryName: 'geom'
  })
  })
 
 Gotcha: er zit een al 2 jaar bekend probleem in PDOK (GeoServer) WFS bij 
 gebruik van WFS 1.1.0: je krijgt standaard GML 3.1.1 output terug, maar 
 daarin zitten 'null' namespaces. Dat weten ze daar ook al 2 jaar, maar 
 heeft blijkbaar geen prio. Daarom als je outputFormat='GML2' opgeeft, 
 gaat het goed. Je kunt ook version: 1.0.0 (default) opgeven dan krijg je 
 standaard GML2 terug. Je kunt zelfs outputFormat=json of zelfs SHAPE-ZIP 
 opvragen...Wie volgt dit nog ;-)?
 
 Goed, ja ik ben deze dagen, vaak knarsetandend, met WFS bezig, dus 
 leuk dit voorbij te zien komen. Overigens kan de 500 error goed met je 
 proxy-instelling, nodig bij OpenLayers+WFS, te maken hebben...
 
 groet!
 
 Just
 
 
 
 On 16-10-13 09:20, Christ van Willegen wrote:
  2013/10/16 nouwsfam nouws...@xs4all.nl:
 
  NetworkError: 500 Internal Server Error -
  http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;
 
  en de foutmelding van de WFS server is nu
 
  Reload the page to get source for:
  http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;
 
  Dat is niet de foutmelding van de WFS server, maar FireBug toont daar
  deze tekst...
 
  Die 'internal server error' is het probleem, maar dan krijg je ook,
  over het algemeen, _geen_ data terug...
 
  Christ van Willegen
 
 
 


Title: Bestuurlijke grenzen




	
	


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


[OSM-talk-nl] Meldingen die verder gaan dan OSM-bugs

2013-10-16 Berichten over hetzelfde onderwerp Stefan de Konink

Goedeavond,


Op zowel het algemeen@openstreetmap als donaties@openstreetmap adres komen 
geregeld dingen binnen die veel verder gaan dan een simpel 'daar is wat fout' 
mailtje. Bijvoorbeeld een mailtje met GPX trace van het gebied. Het lijkt er 
vooral op dat mensen nog net niet de drempel hebben genomen om zelf te gaan 
editen.

Historisch stuur ik dat soort mailtjes dan door naar bijvoorbeeld Floris. Maar 
misschien is er ook iemand anders die wat wil gaan editen aan mailtjes van 
gemeentes (incl. shapebestanden!) of gewoon iemand die een berichtje stuurt dat 
het ergens niet klopt.

Juist met navigatie apparatuur van de Aldi die gewoon werkt op OpenStreetMap is 
het volgens mij erg belangrijk om iemand die de moeite neemt om een berichtje 
te sturen op weg te helpen om zoiets ook zelf aan te kunnen pakken.

Hoe denken jullie hier over, of is er iemand die zegt: stuur maar door? Het 
is niet veel ofzo, maar soms zitten er wel leuke pareltjes tussen :-)


Stefan

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] topologievraag

2013-10-16 Berichten over hetzelfde onderwerp DTeelde
Beste mensen,

Als je kijkt naar de weg Wildpad, dan is deze vanaf de Gotinkveldweg tot de
camping gemapt als unclassified maar met de tag tracktype=grade4. (Is
eigenlijk tegenstrijdig, zie ook de geschiedenis.) Zie
http://www.openstreetmap.org/browse/way/6798321. Op OSM wordt daardoor een
(verharde)weg getekend, maar OpenFietsMap maakt hier een pad van. Ik weet
niet wat de Open MTB Map doet. Open MTB Map gedownload. Ook deze maak er een
pad G4 van.

Bij een route van de kruising Dennendiekske en Hukkersdijk naar Wildpad ter
hoogte van de camping maakt OpenFietsMap inderdaad een zigzag. Open MTB Map
snijdt flink af neemt het pad langs de rand van het bos.
Echter deze weg heeft een tag access=no. Zie
http://www.openstreetmap.org/browse/way/90914432. En is dus blijkbaar niet
toegankelijk. Het lijkt me in dit geval juist dat de OpenFietsMap die zigzag
maakt.

Bij MapSource maakt ook de ingestelde snelheden bij route bepaling ook nog
het nodige verschil. En voor de fietser laat MapSource je inderdaad liever
omrijden dan je over paden te sturen.

Groeten,
Dirk

-Oorspronkelijk bericht-
Van: Geert Ribbers [mailto:ge...@groothagenbeek.nl] 
Verzonden: woensdag 16 oktober 2013 13:48
Aan: 'Minko'; 'OpenStreetMap NL discussion list'
Onderwerp: Re: [OSM-talk-nl] topologievraag

Het gaat goed op Open MTB Map en fout op zowel GR als OFM (die ik eigenlijk
altijd gebruik).
En op zowel instelling kortste afstand als snelste tijd. 
En ook de schuif Wegselectie maakt niets uit (Mapsource).
En het gaat een keer fout bij een fietsroute over het fietspad, maar in het
voorbeeld dat het goed gaat, gaat dezelfde fietsroute over het fietspad. Dus
ook dat maakt niet uit.

Maar wel zie ik nu dat het bij Voertuig Voetganger overal goed gaat. Daar
had ik overheen gekeken blijkbaar.
Daarmee is mijn probleem dus opgelost. 
Bedankt.

Al kan ik dan nog niet begrijpen waarom dat zo is.
In het voorbeeld dat het wel goed gaat bij voertuig fiets komt er een track
met grade5 uit op de combinatie fietspad / zandweg.
Bij de voorbeelden dat het niet goed gaat bij voertuig fiets komt er een pad
op uit.
Dus het verschil hier is track / pad.
Als het correct topologisch aan elkaar zit, zowel het fietspad als de weg
onverhard zijn, waarom zou een fiets dan niet dwars over die combinatie
geleid worden.
Het is echt een hele vreemde lange chicane die gemaakt wordt. Een enorme
omweg, die kan niemand ooit bedoelen.

Maar goed: kennelijk kun je bij een ATB en gewone fiets beter niet kiezen
voor fiets maar voor voetganger.
In een gebied met veel onverharde weggetjes / paden. Als je het maar weet.

Wat cycleway track betreft: ja, als er verschillen in eigenschappen zijn die
aangegeven moeten worden gaat dat niet werken.
Dat is duidelijk.
Zijn die verschillen er niet, dan wordt het er wel simpeler van (en keurig
aangegeven / aan te geven in de stijl evengoed, zie OFM).

Met vriendelijke groet,
Geert Ribbers

-Oorspronkelijk bericht-
Van: Minko [mailto:ligfiet...@online.nl]
Verzonden: woensdag 16 oktober 2013 11:03
Aan: ge...@groothagenbeek.nl; OpenStreetMap NL discussion list
Onderwerp: Re: [OSM-talk-nl] topologievraag

Welk kaart en welke instellingen gebruik je voor het routeren?
De openfietsmap heeft geen problemen met deze wegen, want ze zijn in jouw
voorbeelden als aparte ways ingetekend. Misschien staan je
routeringsinstellingen verkeerd?
Zie http://www.openfietsmap.nl/tips-tricks/mapsource_nl en
http://www.openfietsmap.nl/tips-tricks/basecamp-nl

 Het valt me op dat routeren in Mapsource / Basecamp in een OSM kaart 
 vaak niet goed gaat als een fietspad direct naast een weg gelegen is.
 Meestal is dit een zandweg met een los fietspad ernaast, wat ook 
 uitgevoerd had kunnen zijn als highway=track met cycleway=track.


Ik ben niet zo gecharmeerd van die combinatie. Het is beter deze twee als
aparte ways in te tekenen. Vaak gaat het om wegen met verschillende
eigenschappen, bv het fietspad is geasfalteerd en de track is een zandweg.
Met onverhard vermijden ingeschakeld vermijdt je dan ook dat fietspad omdat
de hoofdrijbaan een track is.
Ik zou cycleway=track hooguit gebruiken op geasfalteerde (hoofd)wegen
waarbij het fietspad bv gescheiden van de rijbaan is met een betonnenrandje
o.i.d. en niet voor zandpaden. 




___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp nouwsfam


Ik ben er uit! Dank jullie allemaal hartelijk. Pff, het was wel een
taaie: ik miste een proxy op mijn thuisserver, dat was het eerste
probleem. Het tweede probleem waren de WFS query instellingen. Sommige
attributen zijn nauwelijks terug te vinden in documentatie (GML2 bv). Ik
heb er nu zoveel mogelijk uitgegooid (geom), en enkele noodzakelijke
toegevoegd (EPSG:900913), en nu werkt het. Zonder jullie hulp was ik er
nooit uitgekomen. 

Dit is nu de query: 

var gemeenteGrenzenLayer = new OpenLayers.Layer.Vector(
Gemeentegrenzen, 
{
strategies: [new OpenLayers.Strategy.BBOX()],
styleMap : gemeenteGrenzenStyleMap, 
protocol: new OpenLayers.Protocol.WFS({
version: 1.1.0,
srsName: 'EPSG:900913',
url: http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs;,
featureType: gemeenten_2012,
featureNS: http://bestuurlijkegrenzen.geonovum.nl;,
outputFormat: 'GML2'
})
}
); 

Hier staat het voorlopige resultaat:
http://83.163.82.100/ontwikkel/maps/rvz/test.html 

Door de proxy worden de gemeentegrenzen inderdaad wat traag geladen via
mijn thuislijntje. Maar het is altijd nog beter dan OSM data via de
Overpass Api (6MB voor alleen al de grenzen in Gelderland). 

Ik heb nog twee wensen: 

a) bepaalde gemeenten uitfilteren. Dat kan waarschijnlijk niet aan de
kant van de WFS server. Dus ik zal een filter in openlayers moeten
aanbrengen, nietwaar? 

b) de data gemeenten_2012 kan ik voor deze toepassing net zo goed lokaal
opslaan (xml) en lokaal laden. Op welke manier moet ik deze data dan
inlezen via OpenLayers? 

Gertjan Idema schreef op 2013-10-16 16:00: 

 Na wat puzzelen, heb ik het voor elkaar.
 In de bijlage een html bestand dat drie open layers lagen produceert:
 - Osm mapnik als achtergrond.
 - Gemeentegrenzen (van 
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs) [7]
 - Woonplaatsgrenzen (van 
 http://geodata.nationaalgeoregister.nl/bagviewer/wfs) [8]
 
 Opvallend is, dat de bagviewer laag werkt zonder de outputFormat: 'GML2' 
 toevoeging.
 
 Verdere voorwaarde is wel dat je de proxy-host goed geconfigureerd hebt.
 Zie hiervoor: 
 http://www.techrepublic.com/blog/diy-it-guy/diy-enable-cgi-on-your-apache-server/
  [9]
 
 Het proxy.cgi script vind je hier: 
 http://trac.osgeo.org/openlayers/browser/trunk/openlayers/examples/proxy.cgi?format=txt
  [10]
 Dit script moet je een klein beetje aan passen, door op regel 18 bij 
 allowedHosts 'geodata.nationaalgeoregister.nl' toe te voegen.
 Als je dat vergeet, krijg je een 'bad gateway' foutmelding.
 
 Houdt er wel rekening dat het even kan duren voor de data geladen is. Met 
 name de woonplaats grenzen.
 Ook vermoed ik, dat door het gebruik van de proxy-host, alle data via jouw 
 server naar de client gaat. Als je een beperkt aantal GB per maand hebt bij 
 je provider, kan dat dus consequenties hebben.
 
 Groeten, Gertjan 
 
 On Wed, 2013-10-16 at 12:08 +0200, Just van den Broecke wrote: 
 
 Ok, welkom in de wondere wereld van WFS en OGC-protocollen :-).
 Het voordeel (boven een expliciete API zoals OSM XAPI) is dat je maar 1 
 protocol spec (WFS) hoeft te kennen. Op grond van een URL zoals 
 geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs moet je alle 
 metadata (types etc) kunnen opvragen. Nadeel is dat WFS 
 onhandig/verbose/redundant in elkaar zit. Meestal 2 stappen om uit te 
 vinden welke parameters je nodig hebt:
 
 GetCapabilities:
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFSrequest=GetCapabilitiesversion=1.1.0
  [1]
 DescribeFeatureType:
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?service=WFSrequest=DescribeFeatureTypeversion=1.1.0
  [2]
 
 Vooral uit de laatste haal je (onderaan) dat de laagnaam 
 'gemeenten_2012' en het geometrie-veld 'geom' moet zijn (bij jou stond 
 'geometrie').
 
 Op grond daarvan heb ik net geprobeerd een OL laag toe te voegen in een 
 viewer waar ik net aan werk (http://kadviewer.kademo.nl [3]) en zie dat dit 
 werkt:
 
 new OpenLayers.Layer.Vector(Bestuurlijke Grenzen - Gemeenten (WFS), {
 strategies: [new OpenLayers.Strategy.BBOX()],
 visibility: false,
 styleMap: new OpenLayers.StyleMap(
 {'strokeColor': '#22', 'fillColor': '#ee', 
 graphicZIndex: 1, fillOpacity: 0.6}),
 protocol: new OpenLayers.Protocol.WFS({
 version: '1.1.0',
 outputFormat: 'GML2',
 srsName: 'EPSG:28992',
 url: 
 http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs [4]?,
 featureType: gemeenten_2012,
 featureNS: http://bestuurlijkegrenzen.geonovum.nl [5],
 geometryName: 'geom'
 })
 })
 
 Gotcha: er zit een al 2 jaar bekend probleem in PDOK (GeoServer) WFS bij 
 gebruik van WFS 1.1.0: je krijgt standaard GML 3.1.1 output terug, maar 
 daarin zitten 'null' namespaces. Dat weten ze daar ook al 2 jaar, maar 
 heeft blijkbaar geen prio. Daarom als je outputFormat='GML2' opgeeft, 
 gaat het goed. Je kunt ook version: 1.0.0 (default) opgeven dan krijg je 
 standaard GML2 terug. Je kunt zelfs outputFormat=json of zelfs SHAPE-ZIP 
 opvragen...Wie volgt dit nog ;-)?
 
 Goed, 

Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp Sebastiaan Couwenberg
On 10/17/2013 12:36 AM, nouwsfam wrote:
 Ik heb nog twee wensen: 
 
 a) bepaalde gemeenten uitfilteren. Dat kan waarschijnlijk niet aan de
 kant van de WFS server. Dus ik zal een filter in openlayers moeten
 aanbrengen, nietwaar? 
 
 b) de data gemeenten_2012 kan ik voor deze toepassing net zo goed lokaal
 opslaan (xml) en lokaal laden. Op welke manier moet ik deze data dan
 inlezen via OpenLayers? 

Ik zou beide wensen combineren door de TOPgrenzen zelf in een PostGIS
database te laden en met MapServer of Geoserver via WFS/WMS te serveren.
Zoals ik in het topic op het forum eerder had gepost. Het is wel wat
meer werk, maar daardoor heb je wel alles in eigen hand om naar
hartenlust aan te passen.

In mijn OpenLayers site heb ik naast de PDOK BAG WFS ook mijn eigen BAG
WFS (momenteel alleen woonplaatsgrenzen), omdat de PDOK BAG WFS niet
genoeg metadata bevat voor wat ik ermee wil doen.

Wederom is de OpenLayers route weer laagdrempeliger. Filteren van WFS
requests is mogelijk. Dit voorbeeld heb je vast al gevonden:

http://dev.openlayers.org/releases/OpenLayers-2.13.1/examples/wfs-filter.html

Dit is voor wens a, voor wens b moet je toch echt met OGC servers aan de
slag. Hoewel je misschien af kan met een caching proxy als zoiets
bestaat voor WFS services.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl


Re: [OSM-talk-nl] nationaalgeoregister WFS service query

2013-10-16 Berichten over hetzelfde onderwerp Just van den Broecke
Voor b. kun je altijd lokaal een JSON evt GML file inladen in een 
OpenLayers Vector Layer. De JSON data haal je in 1x op via (zie ook MvE 
mail) bijv:

http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs?SERVICE=WFSVERSION=1.1.0REQUEST=GetFeatureTYPENAME=bestuurlijkegrenzen:gemeenten_2012SRSNAME=EPSG:900913outputFormat=json

Die bewaar je in een file, zeg gemeenten.json. In OL laadt je die 
lokaal, door deze op je webserver te zetten, zeg in een dir 'data', met 
bijv.


new OpenLayers.Layer.Vector('Gemeenten', {
strategies: [new OpenLayers.Strategy.Fixed()],
protocol: new OpenLayers.Protocol.HTTP({
url: 'data/gemeenten.json',
format: new OpenLayers.Format.GeoJSON()
}),
projection: new OpenLayers.Projection(EPSG:900913)
})

groeten,

Just

On 17-10-13 01:13, Sebastiaan Couwenberg wrote:

On 10/17/2013 12:36 AM, nouwsfam wrote:

Ik heb nog twee wensen:

a) bepaalde gemeenten uitfilteren. Dat kan waarschijnlijk niet aan de
kant van de WFS server. Dus ik zal een filter in openlayers moeten
aanbrengen, nietwaar?

b) de data gemeenten_2012 kan ik voor deze toepassing net zo goed lokaal
opslaan (xml) en lokaal laden. Op welke manier moet ik deze data dan
inlezen via OpenLayers?


Ik zou beide wensen combineren door de TOPgrenzen zelf in een PostGIS
database te laden en met MapServer of Geoserver via WFS/WMS te serveren.
Zoals ik in het topic op het forum eerder had gepost. Het is wel wat
meer werk, maar daardoor heb je wel alles in eigen hand om naar
hartenlust aan te passen.

In mijn OpenLayers site heb ik naast de PDOK BAG WFS ook mijn eigen BAG
WFS (momenteel alleen woonplaatsgrenzen), omdat de PDOK BAG WFS niet
genoeg metadata bevat voor wat ik ermee wil doen.

Wederom is de OpenLayers route weer laagdrempeliger. Filteren van WFS
requests is mogelijk. Dit voorbeeld heb je vast al gevonden:

http://dev.openlayers.org/releases/OpenLayers-2.13.1/examples/wfs-filter.html

Dit is voor wens a, voor wens b moet je toch echt met OGC servers aan de
slag. Hoewel je misschien af kan met een caching proxy als zoiets
bestaat voor WFS services.

Mvg,

Bas




--
kind regards / met vriendelijke groet,

--Just

Just van den Broecke  j...@justobjects.nl
Just Objects B.V. tel +31 65 4268627 Skype: justb4
The Netherlands   http://www.justobjects.nl






___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl