Open IDEmenorca opened 6 months ago
Buenas!
He hecho un poco el friki, que hacía días que no podía "salir al patio" a jugar un rato. Os cuento lo que he realizado:
1.- En una VM con Ubuntu 22.04, he instalado mapproxy siguiendo las directrices de ChatGPT (el santo grial) ya que con las indicaciones de la web, me daba algunos problemas. 2.- Una vez instalado, lo he arrancado:
3.- Esto arranca mapproxy, que por defecto utiliza el puerto 8080:
Se puede acceder a la demo, con el enlace que aparece:
4.- Por defecto, hay configurados distintos servicios de origen diverso: WMS, WMTS, etc. Toda esta configuración está especificada en un fichero .yaml. Es fácil agregar nuevos servicios. Por ejemplo, vamos a agregar el servicio WMS de catastro y el WMS de la capa del camí de cavalls de Menorca:
Si ahora refrescamos la web de mapproxy:
5.- Si ahora hemos un click en el enlace external, no aparece una web con el contenido del capabilities:
Dónde vemos que hay tres capas declaradas en el servicio:
Vamos a comprobar que se cargan las capas y que realmente se está haciendo de proxy:
No he podido cargar la capa de catastro y la del camí de cavalls me aparece sin transparencia. Seguramente será cuestión de acabar de configurar correctamente el fichero de configuración. Tampoco he añadido nuevos SRS y por he trabajado con los que se ofrecen por defecto.
Pero para ser una prueba de concepto no tiene mala pinta.
Qué os parece?
Which features of the service are lost along the way (transparencies, layer descriptions, legendurl, dataurl, styles...). I see in the Mapproxy capabilities that it doesnt' include the attributes of the original capabilities, although I suposo that's a normal behavior considering that Mapproxy is excatly that, a proxy. So it is suposed to redirect all the petitcions to the corresponding wms service... we have to see how that affects the behavior of the API.
If it is possible to create layer groups with one or multiple nesting levels.
Is your feature request related to a problem? Please describe. The sitna api is designed to work based on a single standard WMS service. The very essence of SITMUN is to mashup multiple services in a single aplication. This APISITNA feature has forced the overwriting of some API SITNA functionalities which causes som usage restrictions.
Describe the solution you'd like Using Mapproxy could, potentialy override this issue an allow the native use of API SITNA but with the functionality expected in SITMUN applications.
Describe alternatives you've considered Two usage approaches are visualized, 'a priori':
The first and simplest is to consider Mapproxy as an additional and external piece to SITMUN. Therefore it is placed prior to the definition of layers in the SITMUN administrator.
The second would be to somehow integrate Mapproxy into SITMUN so that the configurations made in the layer tree end up generating a single wms service which is what is communicated to a SITMUN client that works with the SITNA API native (without overwriting anything).
Additional context --Add any other context or screenshots about the feature request here.--