Support for epsg

[gbuompastore]

Please add support for others epsg. I've edit some class to get that.

Can i contribute to repository with my implementation?

-LMap.java -LeafletMapConnector.java -LeafletMapState.java

[mstahv]

Sure and now is a good time to start as I made a largish refactoring (or huge considering the size of the project).

Just fork the project and when you have something ready send me pull request.

BTW. Haven't thought this much, but could we consider making all transformation always on the server side?

[mstahv]

Hi, I'm considering to start using JTS Topology Suite Geometry types in primary API. Internal spatial types would be used only in communication. Do you thing this would affect your work? How do you feel about the idea in general?

[jtreml]

I second the EPSG support! Just a few days ago I had the same need. I didn't get around to implement it though I've seen that all the necessary stuff in the GWT implementation is there. So it should be a rather quick fix. Looking forward to @giulianob83 contribution.

As for JTS, I've used this in quite a few products since it's rather well known and quite complete. I'm a bit on the fence though whether it makes sense to use it for your add-on. With the basic Leaflet functionality I don't think it would add much value. Or do you think otherwise? Also it probably wouldn't hurt too much either. Also I don't have much experience with the draw plugin, maybe in combination with that one it's more useful?

[mstahv]

I came up with the JTS idea while I'm preparing a "reference app" for v-leaflet usage (full stack, domain driven JPA architecture). There I use Hibernate Spatial and some parts start to look quite bad:

LineString path = eventWithPath.getPath(); Coordinate[] coordinates = path.getCoordinates(); org.vaadin.addon.leaflet.shared.Point[] points = new org.vaadin.addon.leaflet.shared.Point[coordinates.length]; for (int i = 0; i < points.length; i++) { Coordinate coordinate = coordinates[i]; points[i] = new org.vaadin.addon.leaflet.shared.Point(coordinate.x, coordinate.y); } LPolyline lPolyline = new LPolyline(points);

// TODO JTS support in v-leaflet would clean this into: // LPolyline lPolyline = new LPolyline(eventWithPath.getPath());

I'll probably build the example app with a helper method, but created an enhancement anyways: https://github.com/mstahv/v-leaflet/issues/18

[jtreml]

Yes, I've quite a few of those cases as well. Exactly the same. Just that in only 20% I'm having them with JTS, most of the time the input I had to deal with is actually either custom type, standard java Point class or just plain old arrays. That's why I said that it would add only limited value.

If it's easy to do and doesn't complicated the code too much, there's probably no harm in integrating JTS. 20% less cases with those extra loops / helpers is still better than always having them ;) But I'd try to not make it the only option. Maybe somehow try to also support arrays and Java Point class.

[mstahv]

I worked a bit on the subject here: https://github.com/mstahv/v-leaflet/commit/1c89a77730a2fbe87993d9e0dfc16d5e9497e573#diff-1295933e1e198b5a829b8b96905a8c12R137

Summary: For JTS fields it is now possible to write a CRFTranslator to translate between any CRS and WSG84 (the currently supported presentation CRS). In tests there is an example how to implement one with geotools.

I guess some use cases could work with this already. A geotools dependency and built in generic helper should be considered?

What are the remaining use cases in this issue?

[jtreml]

Just saw the updates on this issue... great work. As for the remaining use cases, at least the ones we had, they are perfectly covered. It was mainly about being able to use WMS layers that do not offer the standard Mercator projection. (Example here)