Closed sgofferj closed 5 years ago
This is almost certainly an issue with proj4js which this uses to handle projections
On Thu, Jun 27, 2019, 1:19 PM Stefan Gofferje notifications@github.com wrote:
I'm adding a shapefile layer as follows:
var levelStyle = function(feature) {
switch (feature.properties.CNTR_VALUE) { case 0.1: return { weight: 2, color: "rgb(240,130,40)" }; case 1.1: return { weight: 2, color: "rgb(250,60,60)" }; case 2.1: return { weight: 2, color: "rgb(160,0,200)" }; default: return { weight: 0, color: "rgba(0,0,0,0)" }; }
}
var shptest = new L.Shapefile("/charts/leaflet/levels-160.zip", {
style: levelStyle
});
var overlays = {
"Overlays": { "Severe weather levels": levels, "Surface based CAPE": capesfc, "500hPa Geopotential height": gph500hpa }, Test: { Test: shptest }
};
L.control.groupedLayers(basemaps,overlays,{
exclusiveGroups: ["Overlays"]
}).addTo(mymap);
In the map, the shapefile appears to be shifted ~0.25° to the North. When I open the same shapefile in QGIS, it's displayed where it belongs. The shapefile is reprojected from EPSG:4326 to EPSG:3857 with ogr2ogr. Both the original and the reprojected shapefiles display identically in QGIS.
I attach the shapefile in question.
[image: Saakeskus-2019-06-27T17_11_17 204Z] https://user-images.githubusercontent.com/3258466/60286499-54a6e780-9918-11e9-8346-6330eb998fdd.png
[image: Screenshot_20190627_201139] https://user-images.githubusercontent.com/3258466/60286539-625c6d00-9918-11e9-8795-ba719f91376e.png
levels-160.zip https://github.com/calvinmetcalf/leaflet.shapefile/files/3335917/levels-160.zip
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/calvinmetcalf/leaflet.shapefile/issues/60?email_source=notifications&email_token=AAITRH56QF422YHBMT4KMXLP4TZDVA5CNFSM4H36FTZKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G4EIEOA, or mute the thread https://github.com/notifications/unsubscribe-auth/AAITRH4GXXCM33TNMLRDL43P4TZDVANCNFSM4H36FTZA .
I'm not really following. I don't use proj4s. I reproject all my overlays to EPSG:3857 before uploading them to the site.
so anything that's not in 4326 gets projected to that via proj4js
On Fri, Jun 28, 2019 at 10:13 AM Stefan Gofferje notifications@github.com wrote:
I'm not really following. I don't use proj4s. I reproject all my overlays to EPSG:3857 before uploading them to the site.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/calvinmetcalf/leaflet.shapefile/issues/60?email_source=notifications&email_token=AAITRH5GCXVZ3CI5DWIR6ZTP4YMB3A5CNFSM4H36FTZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2GCJA#issuecomment-506749220, or mute the thread https://github.com/notifications/unsubscribe-auth/AAITRHYMTYB3XYNVQRJ45RTP4YMB3ANCNFSM4H36FTZA .
-- -Calvin W. Metcalf
I think you maybe assume to much knowledge on my side. As far as I know, the default projection of leaflet is EPSG:3857. That's why I reproject all shapefiles to that before uploading to my site. So are you saying that your plugin first reprojects everything that's not 4326 to 4326 and then again to 3857? Is the plugin still being maintained Or would it be better if I found another solution? I'm a JS beginner and definitely don't have the skills to do any kind of error analysis, let alone bug fixing on such complex code that I haven't written myself.
so while leaflet does everything in 3857 internally, it does most of its input and output as 4326, specifically via geojson which is almost always in 4326 and that's all this plugin does behind the scenes which is turn your shapefile into geojson and then give that to leaflet.
Your best solution would be to just turn your data into geojson and give that directly to leaflet otherwise if you have a wellformed shapefile this plugin should do the trick.
On Fri, Jun 28, 2019 at 2:15 PM Stefan Gofferje notifications@github.com wrote:
I think you maybe assume to much knowledge on my side. As far as I know, the default projection of leaflet is EPSG:3857. That's why I reproject all shapefiles to that before uploading to my site. So are you saying that your plugin first reprojects everything that's not 4326 to 4326 and then again to 3857? Is the plugin still being maintained Or would it be better if I found another solution? I'm a JS beginner and definitely don't have the skills to do any kind of error analysis, let alone bug fixing on such complex code that I haven't written myself.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/calvinmetcalf/leaflet.shapefile/issues/60?email_source=notifications&email_token=AAITRH7O2Z6LNW6DASQS3N3P4ZILLA5CNFSM4H36FTZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2Z2OQ#issuecomment-506830138, or mute the thread https://github.com/notifications/unsubscribe-auth/AAITRH4QHU4F5ABOKSIJXWLP4ZILLANCNFSM4H36FTZA .
-- -Calvin W. Metcalf
AH! That's rather complicated... But I can confirm that if I don't reproject the shapefiles to 3857, they display correctly, so doesn't seem to be a bug in your plugin. Thanks for the hint with the GeoJSON. I'll try converting my shapefiles to geojson before uploading and see how that works out.
I'm adding a shapefile layer as follows:
In the map, the shapefile appears to be shifted ~0.25° to the North. When I open the same shapefile in QGIS, it's displayed where it belongs. The shapefile is reprojected from EPSG:4326 to EPSG:3857 with ogr2ogr. Both the original and the reprojected shapefiles display identically in QGIS.
I attach the shapefile in question.
levels-160.zip