Play und Scala ist eine gelungene Kombination. Speichern von Geometrien musst du allerdings relativ händisch machen weil ebean (bei Play zum Persistieren dabei) sich nicht leicht um Geometrie-Support erweitern lässt. Eventuell ist aber PostGIS über JDBC anbinden eine gangbare Option für dein Szenario: http://postgis.refractions.net/documentation/manual-2.0/ch06.html#id573790
Danke für die Komplimente bezüglich OLE. Einbinden zum einbinden in Play reichen die kleinen Downloads von http://dl.geops.de/ole/ weil es keine zwingenden serversetitigen Abhängigkeiten gibt.
Es stellt sich nun die Frage wie du die Geometrien in eine Datenbank bekommst. Die kurzfristig einfachste Variante dürfte ein einfaches Datenformat und selber in die Datenbank schreiben sein. Empfehlenswert ist aber GeoServer serverseitig laufen zu lassen und damit Laden und Speichern von Geometrien zu realisieren. Man gewinnt damit eine rudimentäre Rechteverwaltung und vor allem standardisierte Datenformate und Protokolle.
Für die einfachere Variante bietet es sich an das bereits genannte Beispiel zu WFS anzupassen. Grundsätzlich bedarf es mindestens eines Vektor-Layers um darauf zeichnen zu können. Der Layer bekommt eine Strategie um Daten vom Server zu laden – BBOX und Fixed dürften für dich passen. Dann braucht es noch ein Protokoll um zu definieren wie die Daten vom und zum Server kommen – wobei sich WFS und HTTP hier anbieten. Ergänzt werden muss die Kommunikation um die Representation von Geometrien – hier gibt es einige Möglichkeiten aber GeoJSON, WKT und WFS wären die gängigeren.
Ganz konkret sieht es für eine möglichst primitive Variante so aus:
var saveStrategy = new OpenLayers.Strategy.Save({
// automatisch Speichern sobald eine Geometrie gezeichnet ist
auto:true
});
var editLayer = new OpenLayers.Layer.Vector("Test Polygons", {
strategies: [
// Alles im angezeigten Bereich der Karte laden
new OpenLayers.Strategy.BBOX(),
// Oben definiertes automatisches Speichern nutzen
saveStrategy
],
// Einfache Übertragung (für Laden und Speichern)
protocol: new OpenLayers.Protocol.HTTP({
// Teil deiner Anwendung der Daten liefert und Speichert, am einfachsten Requests in Firebug anzeigen
url: "/route/in/deiner/Anwendung",
// Einfaches Textformat nutzen
format: new OpenLayers.Format.WKT()
}),
// Eventuell weitere Optionen
[…]
});
Sinnvoll wäre es auch die Liste der Verfügbaren Werkzeug in Geometrien aus dem Beispiel deutlich zu kürzen. Falls du später danach suchst, es stünde alles zur Verfügung was Dateien in client/lib/Editor/Control/ entspricht.
Zum Weiterlesen bitte die Dokumentation zu OpenLayers beachten. Die Links in Fettschrift lassen sich aufklappen. Die Punkte unter Format, Protocol und Strategy dürften für dich interessant sein: http://dev.openlayers.org/releases/OpenLayers-2.12/doc/apidocs/files/OpenLayers-js.html
Leider ist die Dokumentation von OpenLayers sehr löchrig was des öfteren Lesen deren Quellcodes erfordert.
Es gibt auch noch einen älteren Blog-Artikel, vom dem ein kleiner Teil beschreibt wie auf das Bearbeiten von Geometrien reagiert werden kann. http://www.geops.de/blog/80-ole-und-mapfish-zum-bearbeiten-von-geodaten dann Absnitt „Getting Persistence for OLE“.
Die Umsetzung der Koordinatenliste inklusive Editieren durch manuelle Eingabe wird etwas schwieriger werden. Zumindest die Anzeige könnte man mit getVertices aus OpenLayers.Geometry realisieren. Für weiteres empfehle ich den Code bei dragVertex in https://github.com/openlayers/openlayers/blob/master/lib/OpenLayers/Control/ModifyFeature.js zu lesen.
Wenn der Sinn des manuellen Editierens sein soll, lückenlos zu zeichnen, dann könntest du auch einen Objektfang auf WFS-Daten machen. Das hätte den Vorteil bereits fertig verfügbar zu sein. Das Editieren per manueller Eingabe solltest du hinten anstellen weil das ein ziemlicher Brocken zum selbst implementieren wird.