postgis-workshop/advanced_geometry_construction — Spanish @ OSGeo Weblate: An obvious failure mode of the "furthest from middle" rule …

Translation

English

Spanish

Needs editing

Skip

	English	Spanish	Actions
	Beyond the recursive CTE itself, there are a number of advanced PostgreSQL array features being used here:	Más allá de la propia CTE recursiva, hay una serie de características avanzadas de PostgreSQL que se utilizan aquí:
	We are using ARRAY! PostgreSQL supports arrays of any type. In this case we have an array of integers, but we could also build an array of geometries, or any other PostgreSQL type.	¡Estamos usando ARRAY! PostgreSQL soporta arreglos de cualquier tipo. En este caso tenemos un arreglo de enteros, pero también podríamos construir un arreglo de geometrías, o cualquier otro tipo de PostgreSQL.
	We are using array_append to build up our array of visited identifiers.	Estamos utilizando array_append para construir nuestro vector de identificadores de estación visitados.
	We are using the @> array operator ("array contains") to find which of the Q train stations we have already visited. The @> operators requires ARRAY values on both sides, so we have to turn the individual "gid" numbers into single-entry arrays using the ARRAY[] syntax.	Estamos utilizando el operador de matrices @> ("array contains") para averiguar cuál de las estaciones de tren Q ya hemos visitado. El operador @> requiere valores ARRAY en ambos lados, por lo que tenemos que convertir los números "gid" individuales en arrays con un solo elemento utilizando la sintaxis ARRAY[].
	When you run the query, you get each geometry in the order it is found (which is the route order), as well as the list of identifiers already visited. Wrapping the geometries into the PostGIS `ST_MakeLine <http://postgis.net/docs/ST_MakeLine.html>`_ aggregate function turns the set of geometries into a single linear output, constructed in the provided order.	Al ejecutar la consulta, se obtiene cada geometría en el orden en que se encuentra (que es el orden de ruta), así como la lista de identificadores ya visitados. Envolver las geometrías en la función agregada `ST_MakeLine <http://postgis.net/docs/ST_MakeLine.html>`_ de PostGIS convierte el conjunto de geometrías en una única línea, construida en el orden proporcionado.
	Which looks like this:	La cual luce como:
	Success!	Éxito!
	Except, two problems:	Excepto por dos problemas:
	We are only calculating one subway route here, we want to calculate all the routes.	Aquí sólo estamos calculando una ruta de metro, queremos calcular todas las rutas.
	Our query includes a piece of a priori knowledge, the initial station identifier that serves as the seed for the search algorithm that builds the route.	Nuestra consulta requiere un conocimiento a priori, el identificador inicial de la estación que sirve de semilla para el algoritmo de búsqueda que construye la ruta.
	Let's tackle the hard problem first, figuring out the first station on a route without manually eyeballing the set of stations that make up the route.	Abordemos primero el problema más difícil: averiguar cuál es la primera estación de una ruta sin echar un vistazo manual al conjunto de estaciones que la componen.
	Our 'Q' train stops can serve as a starting point. What characterizes the end stations of the route?	Nuestras paradas del tren "Q" pueden servir de punto de partida. ¿Qué caracteriza a las estaciones finales de la ruta?
	One answer is "they are the most northerly and southerly stations". However, imagine if the 'Q' train ran from east to west. Would the condition still hold?	Una respuesta es "son las estaciones más al norte (septentrionales) y más al sur ( meridionales)". Sin embargo, imagine que el tren "Q" circulara de este a oeste. ¿Se cumpliría la condición?
	A less directional characterization of the end stations is "they are the furthest stations from the middle of the route". With this characterization it doesn't matter if the route runs north/south or east/west, just that it run in more-or-less one direction, particularly at the ends.	Una caracterización menos direccional de las estaciones finales es "son las estaciones más alejadas del centro de la ruta". Con esta caracterización no importa si la ruta discurre en dirección norte/sur o este/oeste, sólo que discurra más o menos en una dirección, sobre todo en los extremos.
	Since there is no 100% heuristic to figure out the end points, let's try this second rule out.	Puesto que no existe una heurística al 100% para averiguar los puntos finales, probemos esta segunda regla.
	An obvious failure mode of the "furthest from middle" rule is a circular line, like the Circle Line in London, UK. Fortunately, New York doesn't have any such lines!	Un fallo obvio de la regla "lo más lejos posible del centro" es una línea circular, como la Circle Line de Londres (Reino Unido). Afortunadamente, Nueva York no tiene líneas de este tipo.
	To work out the end stations of every route, we first have to work out what routes there are! We find the distinct routes.
	Note the use of two advanced PostgreSQL ARRAY functions:
	string_to_array takes in a string and splits it into an array using a separator character. `PostgreSQL supports arrays <http://www.postgresql.org/docs/current/static/arrays.html>`_ of any type, so it's possible to build arrays of strings, as in this case, but also of geometries and geographies as we'll see later in this example.
	unnest takes in an array and builds a new row for each entry in the array. The effect is to take a "horizontal" array embedded in a single row and turn it into a "vertical" array with a row for each value.
	The result is a list of all the unique subway route identifiers.
	We can build on this result by joining it back to the ``nyc_subway_stations`` table to create a new table that has, for each route, a row for every station on that route.
	Now we can find the center point by collecting all the stations for each route into a single multi-point, and calculating the centroid of that multi-point.
	The center point of the collection of 'Q' train stops looks like this:
	So the northern most stop, the end point, appears to also be the stop furthest from the center. Let's calculate the furthest point for every route.
	We've added two sub-queries this time:
	stops_distance joins the centers points back to the stations table and calculates the distance between the stations and center for each route. The result is ordered such that the records come out in batches for each route, with the furthest station as the first record of the batch.
	first_stops filters the stops_distance output by only taking the first record for each distinct group. Because of the way we ordered stops_distance the first record is the furthest record, which means it's the station we want to use as our starting seed to build each subway route.
	Now we know every route, and we know (approximately) what station each route starts from: we're ready to generate the route lines!
	But first, we need to turn our recursive CTE expression into a function we can call with parameters.
	And now we are ready to go!