Arxiu d'Autor
Aplicant la transformació de datum oficial de l’ICGC a PostGIS
Mètodes de transformació disponibles:
- Transformació oficial directa entre EPSG:23031 i EPSG:25831 (mètode elegant)
- 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)
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(*)
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ò…
Disseccionant 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.
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!
Aplicacions de la informació espacial. SIGTE-CAT
Un molt bon video del SIGTE.
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.
En 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.
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…
- “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.