While you can set up a proxy with your webserver, there is an easier way.
First, enable JSONP in GeoServer.
Then form your data requests like this:
var owsrootUrl = 'https://<GEOSERVER URL - CHANGEME>/geoserver/ows';
var defaultParameters = {
service : 'WFS',
version : '2.0',
request : 'GetFeature',
typeName : '<WORKSPACE:LAYERNAME - CHANGEME>',
outputFormat : 'text/javascript',
format_options : 'callback:getJson',
SrsName : 'EPSG:4326'
};
var parameters = L.Util.extend(defaultParameters);
var URL = owsrootUrl + L.Util.getParamString(parameters);
var WFSLayer = null;
var ajax = $.ajax({
url : URL,
dataType : 'jsonp',
jsonpCallback : 'getJson',
success : function (response) {
WFSLayer = L.geoJson(response, {
style: function (feature) {
return {
stroke: false,
fillColor: 'FFFFFF',
fillOpacity: 0
};
},
onEachFeature: function (feature, layer) {
popupOptions = {maxWidth: 200};
layer.bindPopup("Popup text, access attributes with feature.properties.ATTRIBUTE_NAME"
,popupOptions);
}
}).addTo(map);
}
});
This has the additional advantage on working on your test server, as it avoids cross site scripting issues due to the use of JSONP (quoted json objects, from my understanding).
For an example of this in action, see these two maps:
Code here (for posterity).
By the way, I use nginx for the webserver and have the proxy stuff working. If you would like to know how please let me know and I'll edit something in here.
EDIT: another way of getting rid of this error is enabling CORS in either Tomcat (or Jetty, maybe?) or your reverse proxy.
ogr2ogr should do this for you. Looks like you have multiple geometry types in the dataset, not sure how that will work out. You might have to filter out by geometry type. Below not tested. See docs linked to above for inputs and flags.
ogr2ogr -f "GeoJSON" "sqlexport.geojson"
"MSSQL:server=localhost\sqlexpress;database=tempdb;trusted_connection=yes;"
-sql "SELECT * FROM tbl"
Best Answer
To expand on my comment, let me talk about a similar application I had developed to showcase results of an election. There was some data which was updated periodically in the database (i.e. the Results), while most of the data, including the Geometry did not change.
My JavaScript Application used a static GeoJSON file for the static data and Geometry.
I had a C# windows Service on the Server. It periodically queried the database, and dumped the dynamic parts as a JSON file in the WebServer.
My JavaScript Application, periodically queried for the JSON file with a timestamp attached to the GET request, so that it got the latest data. Once the Ajax call received the data, it changed the symbology of the Vector layer.
Part 2 was developed in this way, instead of a normal web service, to reduce the strain on the database. A conventional service would be hit by all clients, and hence there would be many calls to the database. We wanted to avoid that, and cache this data. Hence we proceded with the architecture given in step 2.