Geoinquiets

A Catalunya sóm unes quantes ànimes inquietes amb dèria per la informació geogràfica i les noves tecnologies.

Arxiu d'Autor

Aplicant la transformació de datum oficial de l’ICGC a PostGIS

Mètodes de transformació disponibles:

  1. Transformació oficial directa entre EPSG:23031 i EPSG:25831 (mètode elegant)
  2. Usant fitxer de malla NTv2 (mètode pràctic)

http://www.icgc.cat/ca/Administracio-i-empresa/Eines/Transformacio-de-coordenades-i-formats

Punts de test

Obtinguts del document “Transformació bidimensional de semblança entre ED50 i ETRS89”: http://www.icgc.cat/ca/content/download/48760/337896/version/1/file/H2D_v8.pdf

  • Transformació directa EPSG:23031 => EPSG:25831:
    300000.000 4500000.000 => 299905.060 4499796.515
    315000.000 4740000.000 => 314906.904 4739796.774
    520000.000 4680000.000 => 519906.767 4679795.125
    420000.000 4600000.000 => 419906.005 4599795.760
    
  • Transformació inversa EPSG:25831 => EPSG:23031:
    300000.000 4500000.000 => 300094.938 4500203.485
    315000.000 4740000.000 => 315093.094 4740203.227
    520000.000 4680000.000 => 520093.231 4680204.876
    420000.000 4600000.000 => 420093.993 4600204.241
    

Podem crear una BDD de test a PostGIS amb aquests punts de test:

Crear BDD amb superusuari postgres:

CREATE USER datumtest LOGIN PASSWORD 'datumtest' NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
CREATE DATABASE datumtest OWNER datumtest;
\c datumtest
CREATE EXTENSION postgis;

Després, connectant-se amb l’usari datumtest:

CREATE TABLE ed50_test_points (id serial, geom geometry(Point, 23031));
INSERT INTO ed50_test_points (geom) VALUES
    (ST_GeomFromText('POINT(300000.000 4500000.000)', 23031)),
    (ST_GeomFromText('POINT(315000.000 4740000.000)', 23031)),
    (ST_GeomFromText('POINT(520000.000 4680000.000)', 23031)),
    (ST_GeomFromText('POINT(420000.000 4600000.000)', 23031));

CREATE TABLE etrs89_test_points (id serial, geom geometry(Point, 25831));
INSERT INTO etrs89_test_points (geom) VALUES
    (ST_GeomFromText('POINT(300000.000 4500000.000)', 25831)),
    (ST_GeomFromText('POINT(315000.000 4740000.000)', 25831)),
    (ST_GeomFromText('POINT(520000.000 4680000.000)', 25831)),
    (ST_GeomFromText('POINT(420000.000 4600000.000)', 25831));

Transformació oficial directa entre EPSG:23031 i EPSG:25831

A nivell de PROJ.4

La millor opció seria incloure la transformació com una definició de PROJ.4 a la taula spatial_ref_sys. Malauradament, PROJ.4 no suporta transformacions d’aquest tipus entre sistemes projectats:

http://osgeo-org.1560.x6.nabble.com/How-to-apply-an-affine-transformation-td3842074.html

https://github.com/OSGeo/proj.4/issues/535

A nivell de SQL

En canvi, PostGIS sí que proporciona una funció de tansformació afí, ST_Affine, que es pot aplicar a qualsevol geometria:

ST_Affine(geom, a, b, d, e, xoff, yoff)

Veure: https://postgis.net/docs/ST_Affine.html

Consultant el document oficial de la transformació de semblança de l’ICGC n’obtenim els següents paràmetres de transformació entre ED50 i ETRS89 (per a la projecció UTM, fus 31 N):

  • Tx: -129.549 m
  • Ty: -208.185 m
  • μ: 0.0000015504
  • α: -1,56504 ” = -0.000007587528034836682 rad

Substituïnt valors als paràmetres tal com els anomena PostGIS, obtindriem:

  • a = (1+μ)·cos(α) = 1.0000015503712145
  • b = -(1+μ)·sin(α) = 0.000007587539798467343
  • d = (1+μ)·sin(α) = -0.000007587539798467343
  • e = (1+μ)·cos(α) = 1.0000015503712145
  • xoff = Tx = -129.549
  • yoff = Ty = -208.185

Obtenim la funció ST_Affine:

ST_Affine(geom, 1.0000015503712145, 0.000007587539798467343, -0.000007587539798467343, 1.0000015503712145, -129.549, -208.185)

Podem escriure una funció PLPGSQL que substitueixi totes les geometries d’una taula en EPSG:23031 cap a EPSG:25831:

-- Function: public.icgc_23031_to_25831(character varying, character varying, character varying)

-- DROP FUNCTION public.icgc_23031_to_25831(character varying, character varying, character varying);

CREATE OR REPLACE FUNCTION public.icgc_23031_to_25831(
    schema_name character varying,
    table_name character varying,
    column_name character varying)
  RETURNS text AS
$BODY$
DECLARE
	real_schema name;
	src_srid integer;
	dst_srid integer;
BEGIN
	-- Set SRID values
	src_srid := 23031;
	dst_srid := 25831;
	
	-- Find, check or fix schema_name
	IF ( schema_name != '' ) THEN
		real_schema = schema_name;
	ELSE
		SELECT INTO real_schema current_schema()::text;
	END IF;

	-- Check original SRID
	IF (SELECT count(*) = 0 FROM geometry_columns WHERE f_table_schema = real_schema AND f_table_name = table_name AND f_geometry_column = column_name AND srid = src_srid) THEN
		RAISE EXCEPTION 'table original SRID not matching required SRID %', src_srid;
		RETURN false;
	END IF;

	-- Set new SRID to table metadata
	PERFORM updategeometrysrid(schema_name, table_name, column_name, dst_srid);

	-- Reproject using affine transform
	EXECUTE 'UPDATE ' || quote_ident(real_schema) || '.' || quote_ident(table_name) || ' SET ' || quote_ident(column_name) || ' = ST_Affine('|| quote_ident(column_name) ||', 1.0000015503712145, 0.000007587539798467343, -0.000007587539798467343, 1.0000015503712145, -129.549, -208.185)';

	RETURN real_schema || '.' || table_name || '.' || column_name ||' datum transformed to ' || dst_srid::text;
END;
$BODY$
  LANGUAGE plpgsql VOLATILE STRICT
  COST 100;
ALTER FUNCTION public.icgc_23031_to_25831(character varying, character varying, character varying)
  OWNER TO datumtest;
COMMENT ON FUNCTION public.icgc_23031_to_25831(character varying, character varying, character varying) IS 'args: schema_name, table_name, column_name - Transforms geometries in a table from EPSG:23031 to EPSG:25831 using the official catalan affine transform';

Aquesta funció s’usa així:

SELECT icgc_23031_to_25831('public', 'table_name', 'geom');

Anàlogament, es pot definir la transformació inversa, ETRS89 => ED50, partint dels paràmetres donats per l’ICGC:

  • Tx: 129.547 m
  • Ty: 208.186 m
  • μ: -0.0000015504
  • α: 1,56504 ” = 0.000007587528034836682 rad

Els paràmetres de la matriu de transformació afí serien:

  • a = (1+μ)·cos(α) = 0.9999984495712146
  • b = -(1+μ)·sin(α) = -0.000007587516271060413
  • d = (1+μ)·sin(α) = 0.000007587516271060413
  • e = (1+μ)·cos(α) = 0.9999984495712146
  • xoff = Tx = 129.547
  • yoff = Ty = 208.186

La funció ST_Affine quedaria escrita com:

ST_Affine(geom, 0.9999984495712146, -0.000007587516271060413, 0.000007587516271060413, 0.9999984495712146, 129.547, 208.186)

I, de la mateixa manera, es podria escriure una funció PLSQL per transformar inversament.

 

Usant fitxer de malla NTv2

En aquest cas, ens haurem de baixar el fitxer 100800401.gsb de la web de l’ICGC (http://www.icgc.cat/ca/Administracio-i-empresa/Eines/Transformacio-de-coordenades-i-formats), i copiar-la al lloc on tinguem instal·lat PROJ.4.

A Ubuntu 16.04 la ubicació és /usr/share/proj:

sudo cp 100800401.gsb /usr/share/proj

Llavors cal modificar la definició dels SRS a la taula spatial_ref_sys:

update spatial_ref_sys set proj4text = '+proj=utm +zone=31 +ellps=intl +units=m +no_defs +nadgrids=100800401.gsb' where srid = 23031;
update spatial_ref_sys set proj4text = '+proj=longlat +ellps=intl +no_defs +nadgrids=100800401.gsb' where srid = 4230;

Comprovació fent servir les taules d’exemple:

SELECT ST_AsEWKT(geom), ST_AsEWKT(ST_Transform(geom, 25831)) from ed50_test_points; SELECT ST_AsEWKT(geom), ST_AsEWKT(ST_Transform(geom, 23031)) from etrs89_test_points;


Oscar Fonts (geomati.co)

 

Written by oscarfonts

14 Mai 2018 at 14:17

Arxivat a receptes

Principis de disseny – serveis digitals del govern del Regne Unit

Una guia envejable, que valia la pena traduir al català: https://www.gov.uk/designprinciples

Començar per les necessitats(*)

(*)les dels usuaris, no les del govern

El procés de disseny ha de començar amb la identificació i pensant en les necessitats reals dels usuaris. Hem de dissenyar al voltant d’aquestes, no al voltant de la forma en què el “procés oficial” funciona en aquest moment. Hem d’entendre aquestes necessitats a fons, contrastant dades, no només fent suposicions, i hem de recordar que el que els usuaris demanen no sempre és el que necessiten.

Per exemple, cal ser clar, destacant aquella informació que sabem que busca la majoria d’usuaris.

Fer menys

El Govern hauria de fer només el que el govern pot fer. Si algú altre ja ho està fent, enllacem-ho. Si som capaços de proporcionar els recursos (com APIs) per ajudar altres persones a construir coses, fem-ho. Ens hem de concentrar en el nucli irreductible.

Proporcionarem millor servei i estalviarem diners concentrant els recursos allà on sigui més profitós.

Dissenyar en base a dades

Habitualment no comencem de zero, els usuaris ja estan utilitzant els nostres serveis. Per tant podem aprendre del comportament del món real. Hem de fer-ho inicialment, però també assegurar-nos que continuarem fent-ho en el procés de desenvolupament: creació de prototips i proves, amb usuaris reals, al web i en viu. Hem de descobrir quins són els camins naturals en base a les dades recollides, i aplicar-los als nostres dissenys.

Aquest és el gran avantatge dels serveis digitals: podem observar i aprendre de la conducta de l’usuari i adaptar els sistemes al comportament natural de la gent, enlloc d’obligar la gent a adaptar-se al sistema que haguem inventat.

Treballar dur per fer-ho fàcil

Fer que alguna cosa sembli simple és fàcil; fer alguna cosa fàcil d’usar és molt més difícil, especialment quan els sistemes subjacents són complexes. Però això és el que hauríem d’estar fent.

Un gran poder comporta una gran responsabilitat. Molt sovint les persones no tenen més remei que utilitzar els nostres serveis. Si no treballem dur perquè siguin senzills i útils, estem abusant d’aquest poder i estem fent perdre el temps a la gent.

Iterar. I després tornar a iterar

La millor manera de construir serveis eficaços és començar amb poc i iterar com a bojos. Publicar quan abans el Mínim Producte Viable, testejar amb usuaris reals, i passar d’Alfa a Beta al Llançament afegint funcionalitats i millores en base als comentaris dels usuaris reals.

La iteració minimitza el risc, reduint la probabilitat de cometre grans errors, i convertint els petits errors en lliçons. Així s’eviten els documents d’especificacions de 200 pàgines que poden ser un veritable coll d’ampolla. Novament, aquest és l’avantatge principal de la tecnologia digital: no estem construint ponts, les coses es poden modificar en qualsevol moment.

Construir per a la inclusió

El disseny accessible és el bon disseny. Hem de construir un producte que sigui tan inclusiu, llegible i comprensible com sigui possible. Si hem de sacrificar l’elegància, que així sigui. No hem de tenir por del que és obvi, no hem de tractar de reinventar les convencions del disseny web, i hem de satisfer les expectatives amb claredat.

Estem dissenyant per a tot el país, no només per als que estan acostumats a fer servir la web. De fet, les persones que més necessiten dels nostres serveis sovint són aquelles que els troben més difícils d’utilitzar. Si pensem en aquestes persones en primer lloc, farem un millor web per a tots.

Comprendre el context

No estem dissenyant per a una pantalla, estem dissenyant per a la gent. Hem de pensar molt bé el context en el qual la gent està utilitzant els nostres serveis: Estan en una biblioteca? Accedeixen des d’un telèfon? Potser només se senten realment familiaritzats amb el Facebook? Han utilitzat mai la web abans?

Estem dissenyant per a un grup molt divers d’usuaris amb tecnologies i necessitats molt diferents. Hem d’assegurar-nos que hem entès les circumstàncies tecnològiques i pràctiques en què s’utilitzen els nostres serveis. Altrament, correm el risc de dissenyar serveis maquíssims, però irrellevants per a la vida de les persones.

Construir serveis digitals, no llocs web

El nostre servei no comença i acaba al nostre lloc web. Podria començar en un motor de cerca i acabar a una oficina de correus. Hem de dissenyar per a aquest entorn, tot i que no el poguem controlar. I cal assumir que un dia, abans d’adonar-nos-en, la nostra feina consistirà en proporcionar tota una altra mena de serveis digitals.

No es tracta de fer llocs web, es tracta de proporcionar serveis digitals. En aquest moment, la millor manera d’oferir serveis digitals és a través del web, però això pot canviar, potser abans del que hàgim previst.

Ser coherents, no uniformes

Sempre que sigui possible cal utilitzar el mateix llenguatge i els mateixos patrons de disseny, això ajuda a les persones a familiaritzar-se amb els nostres serveis. Ara bé, quan això no sigui possible, hem de garantir que la nostra manera d’adreçar-nos-hi sigui coherent. De tal manera que els nostres usuaris tinguin l’oportunitat d’intuir què és el que cal fer en cada moment.

Això no és un llibre normatiu. No podrem construir grans serveis aplicant mecànicament una sèrie de receptes. No podem imaginar totes les situacions possibles i escriure’n les regles. Cada circumstància és diferent i ha de ser abordada en els seus propis termes. El que ha de relligar les coses, doncs, és un enfocament consistent, aquell que, amb sort, els usuaris arribaran a aprendre i en el que confiaran, fins i tot a mesura que avancem cap a nous escenaris digitals.

Treballar en obert millora les coses

Sempre que puguem, hem de compartir el que fem. Amb companys de feina, amb els usuaris, amb el món. Compartir codi, compartir dissenys, compartir idees, compartir intencions, compartir fracassos. Com més ulls hi ha posats en un servei, millor es torna: se’n descobreixen les pífies, s’identifiquen millors alternatives, s’apuja el llistó.

En part perquè molt del que estem fent només ha estat possible gràcies al codi obert i a la generositat de la comunitat de dissenyadors web, i hi estem en deute. Però sobretot perquè a major obertura, millors serveis: millor compresos i més escodrinyats. Si regalem el nostre codi, se’ns retornarà en forma de millor codi. Per això estem compartint tot això…

Written by oscarfonts

2 Mai 2013 at 16:44

Arxivat a General

Disseccionant OpenStreetMap

OpenStreetMap

OpenStreetMap

El passat 23F vam fer una geoinquietada sobre OpenStreetMap. En Jaume Figueras ens en va parlar, aquí teniu la presentació:

Com veieu, aquesta vegada no es tractava d’aprendre a fer anar el GPS i l’editor JOSM per dibuixar el mapa, sinó d’una classe magistral on vam repassar aspectes tècnics: Quines primitives geomètriques s’utilitzen, com funciona l’etiquetatge, què hi ha al wiki, com utilitzar les diferents APIs per extreure’n les dades… en resum, una pastilla de caldo concentrat que sintetitza les claus per si mai volem treballar amb les dades crues o muntar el nostre propi servidor à la OSM.

Si voleu afegir-vos a la comunitat OSM a Espanya, apunteu-vos a la llista de correu [Talk-es].

Aquell dia vam ser: Marc, Oscar, Àlex, Enric, Vitor, Pedro, Javier, Alejandra, Elena, Juancho, BOLO i Anna.

Written by oscarfonts

6 Març 2011 at 11:50

Un any de Geoinquiets

Barcelona estava a punt de convertir-se en la seu mundial del geofrikisme, i l’homenet verd se’n feia creus: “en barzelona tiene que haber comunidad”.

“A Catalunya sóm unes quantes ànimes inquietes amb dèria per la informació geogràfica i les noves tecnologies”

Així obria el convit iniciàtic fa poc més d’un any. I així va ser. El darrer dissabte de gener ens vam trobar per primer cop al Centro Galego de Barcelona. Curiós, aquell dia també erem setze. I de seguida ens vam autoproclamar geoinquiets. En una setmana tenim la llista de correu funcionant a OSGeo. S’hi van succeïr dues trobades més, on, a més del frenesí per reclutar voluntarietats per la causa del programari lliure, de seguida van començar els primers debats encesos sobre la nostra autèntica dèria: les dades.

Passades les nevades de Març i les Jornades de Girona, la quarta trobada va ser al voltant d’un sofà. Moments de reflexió, de decisions en petit comitè i punt d’inflexió. Aquí vam començar a marcar el que serien les geoinquietades més enllà del FOSS4G.

I vam començar a convidar gent que ens parlarà dels seus projectes:

05/06/2010 – askaro.com (Ubaldo Huerta), arqueologia del paisatge (Hèctor A. Orengo).

08/07/2010 – Urbiòtica (Irene Compte), eixos.planol.info (David Nogué).

30/09/2010 – Wikiloc (Jordi L. Ramot).

21/10/2010 – Projecte EDIT (Pere Roca Ristol).

02/12/2010 – Administració Oberta (Jordi Graells).

27/01/2010 – Realitat Augmentada (Estela Llorente, David Nogué, Marc Torres).

Entre tant, han passat el SotM i el FOSS4G, vam estrenar blog i domini, tenim entre mans un article, i ens posarem mans a l’obra intentant jugar amb les dades obertes de que disposem.

Ah, i ja sóm 60 inscrits a la llista!

Per molts anys!

Written by oscarfonts

31 gener 2011 at 17:11

Arxivat a resum

Aplicacions de la informació espacial. SIGTE-CAT

Un molt bon video del SIGTE.

Written by oscarfonts

2 Octubre 2010 at 17:36

Arxivat a General

Presentació de Wikiloc

Dijous passat, 30 de setembre, vam tenir l’honor de parlar anb en Jordi Ramot, creador de Wikiloc, rutes del món.

Wikiloc logoEn aquesta ocasió, com que érem una colla de frikis, va enfocar la seva presentació en aspectes més tècnics, sobre com està muntada l’aplicació, i sobre el procés d’evolució d’un projecte d’aquestes característiques.

Aquí teniu la presentació d’en Jordi:

I algunes notes sobre la presentació:
En Jordi Ramot és informàtic. Comença a un ajuntament, on descobreix què és això del SIG, i després entra a treballar a Nexus Geografics.

Els caps de setmana, en les seves sortides amb BTT, comença a grabar rutes amb un Garmin de quan els GPS encara eren aparells estranys per a la majoria… i troba a faltar un web on compartir les rutes.
Es va fer autònom. I va tenir prou estones per començar a desenvolupar l’eina que trobava a faltar: Wikiloc.
Al principi, l’eina es va concebre fent servir les eines que es feien servir en desenvolupaments corporatius: Oracle Spatial, servidor d’aplicacions d’Oracle, i un mapserver. Estava enfocada a l’àmbit de Catalunya.
El 2005, apareix Google Maps. Era una aplicació de base potent, ràpida, amb cartografia de tot el món, i amb una API per fer mash-ups! Això fa replantejar el projecte, que comença de nou sobre Google Maps, i es converteix en un projecte d’abast mundial.
El 7 abril 2006 es posa on-line, i s’anuncia mitjançant  un missatge a la llista de RedIRIS de GPS. L’endemà al matí ja hi havia 25 usuaris registrats, i 60 itineraris pujats, inclús a la Patagònia!
Sense la API de Google Maps, segurament s’hagués abandonat el projecte. Disposar del software, les llicències,  i les dades a nivell mundial implicava mobilitzar massa recursos…

Wikiloc va començar com una eina trilingüe, en català, castellà i anglès. Ara mateix és traduït a 18 idiomes, per voluntaris. La primera traducció de la comunitat va ser a l’Euskera.

El 2008 es signa un acord amb Google, i els continguts són exportats a Google Earth setmanalment. Una bona plataforma de difusió (s’estima que hi ha 450 milions d’instàncies de Google Earth instal·lades), i una bona eina de visualització (el 3D ajuda molt a ‘veure’ les rutes abans de sortir de casa). Com acustuma a passar, la part més feixuga de l’acord no van ser els aspectes tècnics, sinó els legals…

Wikiloc és una aplicació que s’executa al navegador de cada usuari, i accedeix a una plataforma de serveis distrubuïts a la xarxa. Això fa que, amb pocs recursos, l’aplicació sigui molt escalable: moltes coses no passen pel servidor de Wikiloc, i s’aprofiten serveis fantàstics, com per exemple els de geonames per obtenir dades d’alçada (que posa a disposició els models DEM STRM i ASTER).
El procés d’aprenentatge i d’evolució de l’aplicació és… diguem-ho clar: a base d’hòsties. Molts cops el desenvolupador d’una aplicació presuposa quines seran les necessitats dels usuaris… i resulta que “la gent no té les necessitats que tu creus”.
Cal observar el comportament dels usuaris: registrar quins tipus de consultes fan, quines eines i accions són les que realment es fan servir. I tractar de posar-s’ho fàcil.
Anecdotari d’entrebancs:
  • “Per què no hi ha rutes a Canadà?” Perquè es redirigia cap al subdomini “ca”, i sortia la pàgina en català! La localització s’ha de vigilar, pots despistar països sencers.
  • L’etern malson del desenvolupador web: com pot ser que la gent encara faci servir IE6!?
  • Amenaces legals – casos en que t’intenten fer responsable dels continguts que la gent hi posa.
  • Control d’abusos – algun cas de pujada massiva d’informació sense interès.
  • Escalabilitat – efecte shashdot. Publiquen a algun mitjà de comunicació, i pugen les visites sobtadament.

Tecnologia emprada:

  • Llenguatges: Java, Python, Shell scripts.
  • Frameworks: Struts, Spring, Hibernate.
  • Llibreries: ImageMagick, GPSBabel.
  • Base de dades: PostgreSQL, PostGIS.
  • Servidor aplicacions: Apache Tomcat.
  • Servidor HTTP: NGINX (minimalista, rendiment òptim).
  • Sistema Operatiu: Linux (CentOS).
  • Hardware: Un únic servidor! (EUA, Alemanya).

I entre tantes rutes, com triar les bones? S’ha establert un indicador/rànquing de qualitat que es computa automàticament valorant un conjut de factors: Densitat dels punts a les rutes, quantitat de fotografies, reputació de l’usuari, etc. Les rutes amb puntuació més alta, apareixen abans a la llista de resultats.

I el model de negoci? Es pot viure de Wikiloc? …de moment no, però s’està estudiant la manera de fer-ho, sense traïr l’esperit del lloc ni emprenyar els usuaris: spamejar amb campanyes comercials no sembla la millor manera.

Written by oscarfonts

2 Octubre 2010 at 12:14