Re: [Qgis-user] plugin to find boundaries around points
On Mon, 10 Dec 2018 at 03:42, Holly Allen wrote: > > I've stumbled onto QGIS through a work project, and have a specific problem > I'm trying to solve. We have a set of around 5000 locations which are broken > up into about 500 districts. We'd like to produce a map of polygons > representing the districts, and I would really, really like to not do that by > hand if I can. > > I've poked around in QGIS a bit (mostly 3.4.2, but I also installed the > latest 2.x version briefly to check it out) and worked through the list of > plugins available, and I don't see a way to auto-generate boundaries between > groups of points. I am about to write the code myself, but wanted to ask the > group whether I'm just missing something obvious. Please point me to anything > I'm missing! Since I haven't done anything in this field before, I may simply > not be searching for the right terms. Bonus points if I can take the > resulting boundaries and have them snap to state boundaries (in another > layer) wherever the state boundaries happen to fall between the groups. My suggested approach: 1. If you don't already have "districts" assigned to the points, run the DB Scan processing algorithm to auto-assign points to a logical cluster 2. Run voronoi polygons on the points 3. Dissolve the voronoi polygons based on either the existing district field (or the cluster id assigned by DB scan) 4. Run the "snap geometries to layer" tool to attempt to realign the dissolved voronoi polygon borders to your existing state boundaries (within a suitable distance tolerance) Nyall > > Thanks, > Holly > ___ > Qgis-user mailing list > Qgis-user@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] plugin to find boundaries around points
Hi, In the Processing toolbox, QGIS provides a lot of algorithms to create bounding boxes, under "Vector geometry" group. You may want to give them a look. Harrissou Le dim. 9 déc. 2018 à 20:14, Havard Tveite a écrit : > Assuming that the point layer has an attribute that identifies > the district, I suggest that you first create Voronoi polygons > for the point layer, and then dissolve the Voronoi polygons based > on the attribute that identifies the district. > Both these functions can be found in the Processing toolbox. > The QGIS Voronoi algorithm was fixed recently, so if you do not > have the latest QGIS version you should use v.voronoi (GRASS). > > Håvard > > On 09.12.2018 18:35, Holly Allen wrote: > > I've stumbled onto QGIS through a work project, and have a specific > > problem I'm trying to solve. We have a set of around 5000 locations > > which are broken up into about 500 districts. We'd like to produce a map > > of polygons representing the districts, and I would really, really like > > to not do that by hand if I can. > > > > I've poked around in QGIS a bit (mostly 3.4.2, but I also installed the > > latest 2.x version briefly to check it out) and worked through the list > > of plugins available, and I don't see a way to auto-generate boundaries > > between groups of points. I am about to write the code myself, but > > wanted to ask the group whether I'm just missing something obvious. > > Please point me to anything I'm missing! Since I haven't done anything > > in this field before, I may simply not be searching for the right terms. > > Bonus points if I can take the resulting boundaries and have them snap > > to state boundaries (in another layer) wherever the state boundaries > > happen to fall between the groups. > > > > Thanks, > > Holly > > > > ___ > > Qgis-user mailing list > > Qgis-user@lists.osgeo.org > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > > > ___ > Qgis-user mailing list > Qgis-user@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] plugin to find boundaries around points
Assuming that the point layer has an attribute that identifies the district, I suggest that you first create Voronoi polygons for the point layer, and then dissolve the Voronoi polygons based on the attribute that identifies the district. Both these functions can be found in the Processing toolbox. The QGIS Voronoi algorithm was fixed recently, so if you do not have the latest QGIS version you should use v.voronoi (GRASS). Håvard On 09.12.2018 18:35, Holly Allen wrote: I've stumbled onto QGIS through a work project, and have a specific problem I'm trying to solve. We have a set of around 5000 locations which are broken up into about 500 districts. We'd like to produce a map of polygons representing the districts, and I would really, really like to not do that by hand if I can. I've poked around in QGIS a bit (mostly 3.4.2, but I also installed the latest 2.x version briefly to check it out) and worked through the list of plugins available, and I don't see a way to auto-generate boundaries between groups of points. I am about to write the code myself, but wanted to ask the group whether I'm just missing something obvious. Please point me to anything I'm missing! Since I haven't done anything in this field before, I may simply not be searching for the right terms. Bonus points if I can take the resulting boundaries and have them snap to state boundaries (in another layer) wherever the state boundaries happen to fall between the groups. Thanks, Holly ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [QGIS-it-user] QGIS 2.18 LTR e il SR epsg 25833
Grazie per il tuo test. Le tue considerazioni convergono con le mie. Grazie di nuovo. Il giorno dom 9 dic 2018 alle ore 11:20 Martina Savarese < martina.savar...@gmail.com> ha scritto: > Allora ho fatto varie prove su quel pezzetto e confrontando i raster il > massimo scostamento che ho trovato è di circa 2m, MA a quella scala i pixel > sono troppo grandi per poter fare una misurazione corretta. Quindi mi sono > caricata shape vecchi e nuovi e dxf vecchi (ho preso le curve di livello, > perchè lì non c'è molto altro) e lo scostamento massimo riscontrato è di > circa 1,7/1,8 ma di media è inferiore a 1m. > A questo punto per poter dire quale delle due versioni cartografiche è più > corretta ho caricato l'ortofoto 2012 del Geoportale nazionale e confrontato > l'unica stradina che c'è (nota bene che per quel quadrante gli shp della > nuova ctr sono quelli del quadrante RM376, e non li trovi quindi nella > provincia di Frosinone ma di Roma). > Conclusione: secondo me la nuova ctr è quella più corretta, nel senso che > almeno per quella stradina è più aderente all'ortfoto del Geoportale > nazionale, mentre quella vecchia è maggiormente traslata verso est. > > Ho fatto le prime prove (sulle curve di livello) sia sulla versione 3.18 > che sulla 3.4 e mi danno gli stessi risultati, l'ortofoto invece l'ho > caricata solo sulla 3.4 ma direi che a rigor di logica dovrebbe dare gli > stessi risultati anche quella. > > Secondo me dovresti controllare di avere l'ultima versione dlla 2.18 e > come è impostato l'ellissoide nelle proprietà progetto (tab generale, sotto > il gruppo misurazioni): settalo a none/planimetric o GRS180. > > Martina > > Il giorno sab 8 dic 2018 alle ore 22:22 Marco Spaziani < > spaziani.ma...@gmail.com> ha scritto: > >> Basta. Ci rinuncio. Mi sono incartato. Io mi arrendo. Ho provato in tutti >> i modi ma non ci riesco. >> Se volete provarci voi vi propongo un test facile facile, tanto per >> capire se sono io lo scemo del villaggio o se invece c'è qualcosa che non >> va. >> Andate qui: >> >> http://dati.lazio.it/catalog/it/dataset/2014-carta-tecnica-regionale-numerica-scala-1-5-000-provincia-di-frosinone/resource/863936db-bcbd-429f-8b62-9986a1d1ab13 >> e scaricatevi il raster 376042 impostato nel sistema di riferimento EPSG >> 25833 e relativo alla CTR del 2014 >> Poi andate qui: >> >> http://dati.lazio.it/catalog/it/dataset/carta-tecnica-regionale-2009-5k-frosinone/resource/f5c7cd76-9c1b-4cc3-86d1-75bfc3109353 >> e scaricatevi l'analogo raster 376042 impostato nel sistema di >> riferimento EPSG 3004 e relativo alla CTR del 2009. >> Una volta scaricati, aprite un progetto in QGIS, impostate il SR che >> volete, selezionate la "riproiezione al volo" e importate i due raster che >> avete appena scaricato, (e che sono relativi alla stessa identica porzione >> di territorio), quindi a uno dei due raster date un 50% di trasparenza e >> vedete un po cosa vi viene fuori. >> A me mi viene il solito spostamento di circa 3 m verso NW di uno rispetto >> all'altro (per apprezzarlo zoomate alla scala 1:500 e guardate il sentiero >> che passa vicino al confine della provincia/comune). >> Vi ho proposto il raster 376042 perchè sono solo 4Mb di dati scaricare e >> fate subito, ma il confronto lo potete fare con quello che volete, raster o >> shape file che sia ...io le ho provate tutte, raster con raster, shape con >> shape, raster con shape ... e sempre uno spostamento di circa 3 m mi viene. >> Secondo voi dov'è il problema? sono io che non so usare il SR 25833? >> ...è QGIS che non sa riproiettare il SR 25833? ...è il data set >> cartografico della Regione che contiene cartografia bacata? >> Fatemi sapere. >> Grazie >> >> >> >> >> Il giorno sab 8 dic 2018 alle ore 00:02 Martina Savarese < >> martina.savar...@gmail.com> ha scritto: >> >>> Sono la stessa cosa in due lingue diverse (in parole poverissime) >>> QGS usa proj4, la specifica che trovi nel file prj è esri wkt. Se vai su >>> epsg.io e fai la ricerca di un qualsiasi epsg in fondo alla pagina >>> trovi (mi pare sia sotto la voce esporta, ma ora non ho il computer sotto >>> mano) la possibilità di esprimere quel epsg in vari formati; cliccali uno >>> per uno e vedi in quanti modi si può dire secondo in cosa stai lavorando >>> >>> Martina >>> >>> Il giorno Ven 7 Dic 2018 23:28 Marco Spaziani >>> ha scritto: >>> In realtà la stringa contenuta nel file PRJ degli shape file è un po' più "lunga" di quella che hai suggerito tu e, precisamente, è: PROJCS["ETRS_1989_UTM_Zone_33N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",50.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",15.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]] Nell'elenco dei SR di QGIS 2.18 LTR, il SR è esplicitato con la
Re: [QGIS-it-user] QGIS 2.18 LTR e il SR epsg 25833
piuttosto dal raster della ctr ho notato che è cambiato il confine regionale con l'Abruzzo (non lo sapevo e mi sono dimenticata di fare verifiche sui vettoriali e su confini istat, magari la prossima settimana controllo) Martina Il giorno Dom 9 Dic 2018 11:19 Martina Savarese ha scritto: > Allora ho fatto varie prove su quel pezzetto e confrontando i raster il > massimo scostamento che ho trovato è di circa 2m, MA a quella scala i pixel > sono troppo grandi per poter fare una misurazione corretta. Quindi mi sono > caricata shape vecchi e nuovi e dxf vecchi (ho preso le curve di livello, > perchè lì non c'è molto altro) e lo scostamento massimo riscontrato è di > circa 1,7/1,8 ma di media è inferiore a 1m. > A questo punto per poter dire quale delle due versioni cartografiche è più > corretta ho caricato l'ortofoto 2012 del Geoportale nazionale e confrontato > l'unica stradina che c'è (nota bene che per quel quadrante gli shp della > nuova ctr sono quelli del quadrante RM376, e non li trovi quindi nella > provincia di Frosinone ma di Roma). > Conclusione: secondo me la nuova ctr è quella più corretta, nel senso che > almeno per quella stradina è più aderente all'ortfoto del Geoportale > nazionale, mentre quella vecchia è maggiormente traslata verso est. > > Ho fatto le prime prove (sulle curve di livello) sia sulla versione 3.18 > che sulla 3.4 e mi danno gli stessi risultati, l'ortofoto invece l'ho > caricata solo sulla 3.4 ma direi che a rigor di logica dovrebbe dare gli > stessi risultati anche quella. > > Secondo me dovresti controllare di avere l'ultima versione dlla 2.18 e > come è impostato l'ellissoide nelle proprietà progetto (tab generale, sotto > il gruppo misurazioni): settalo a none/planimetric o GRS180. > > Martina > > Il giorno sab 8 dic 2018 alle ore 22:22 Marco Spaziani < > spaziani.ma...@gmail.com> ha scritto: > >> Basta. Ci rinuncio. Mi sono incartato. Io mi arrendo. Ho provato in tutti >> i modi ma non ci riesco. >> Se volete provarci voi vi propongo un test facile facile, tanto per >> capire se sono io lo scemo del villaggio o se invece c'è qualcosa che non >> va. >> Andate qui: >> >> http://dati.lazio.it/catalog/it/dataset/2014-carta-tecnica-regionale-numerica-scala-1-5-000-provincia-di-frosinone/resource/863936db-bcbd-429f-8b62-9986a1d1ab13 >> e scaricatevi il raster 376042 impostato nel sistema di riferimento EPSG >> 25833 e relativo alla CTR del 2014 >> Poi andate qui: >> >> http://dati.lazio.it/catalog/it/dataset/carta-tecnica-regionale-2009-5k-frosinone/resource/f5c7cd76-9c1b-4cc3-86d1-75bfc3109353 >> e scaricatevi l'analogo raster 376042 impostato nel sistema di >> riferimento EPSG 3004 e relativo alla CTR del 2009. >> Una volta scaricati, aprite un progetto in QGIS, impostate il SR che >> volete, selezionate la "riproiezione al volo" e importate i due raster che >> avete appena scaricato, (e che sono relativi alla stessa identica porzione >> di territorio), quindi a uno dei due raster date un 50% di trasparenza e >> vedete un po cosa vi viene fuori. >> A me mi viene il solito spostamento di circa 3 m verso NW di uno rispetto >> all'altro (per apprezzarlo zoomate alla scala 1:500 e guardate il sentiero >> che passa vicino al confine della provincia/comune). >> Vi ho proposto il raster 376042 perchè sono solo 4Mb di dati scaricare e >> fate subito, ma il confronto lo potete fare con quello che volete, raster o >> shape file che sia ...io le ho provate tutte, raster con raster, shape con >> shape, raster con shape ... e sempre uno spostamento di circa 3 m mi viene. >> Secondo voi dov'è il problema? sono io che non so usare il SR 25833? >> ...è QGIS che non sa riproiettare il SR 25833? ...è il data set >> cartografico della Regione che contiene cartografia bacata? >> Fatemi sapere. >> Grazie >> >> >> >> >> Il giorno sab 8 dic 2018 alle ore 00:02 Martina Savarese < >> martina.savar...@gmail.com> ha scritto: >> >>> Sono la stessa cosa in due lingue diverse (in parole poverissime) >>> QGS usa proj4, la specifica che trovi nel file prj è esri wkt. Se vai su >>> epsg.io e fai la ricerca di un qualsiasi epsg in fondo alla pagina >>> trovi (mi pare sia sotto la voce esporta, ma ora non ho il computer sotto >>> mano) la possibilità di esprimere quel epsg in vari formati; cliccali uno >>> per uno e vedi in quanti modi si può dire secondo in cosa stai lavorando >>> >>> Martina >>> >>> Il giorno Ven 7 Dic 2018 23:28 Marco Spaziani >>> ha scritto: >>> In realtà la stringa contenuta nel file PRJ degli shape file è un po' più "lunga" di quella che hai suggerito tu e, precisamente, è:
Re: [QGIS-it-user] QGIS 2.18 LTR e il SR epsg 25833
Allora ho fatto varie prove su quel pezzetto e confrontando i raster il massimo scostamento che ho trovato è di circa 2m, MA a quella scala i pixel sono troppo grandi per poter fare una misurazione corretta. Quindi mi sono caricata shape vecchi e nuovi e dxf vecchi (ho preso le curve di livello, perchè lì non c'è molto altro) e lo scostamento massimo riscontrato è di circa 1,7/1,8 ma di media è inferiore a 1m. A questo punto per poter dire quale delle due versioni cartografiche è più corretta ho caricato l'ortofoto 2012 del Geoportale nazionale e confrontato l'unica stradina che c'è (nota bene che per quel quadrante gli shp della nuova ctr sono quelli del quadrante RM376, e non li trovi quindi nella provincia di Frosinone ma di Roma). Conclusione: secondo me la nuova ctr è quella più corretta, nel senso che almeno per quella stradina è più aderente all'ortfoto del Geoportale nazionale, mentre quella vecchia è maggiormente traslata verso est. Ho fatto le prime prove (sulle curve di livello) sia sulla versione 3.18 che sulla 3.4 e mi danno gli stessi risultati, l'ortofoto invece l'ho caricata solo sulla 3.4 ma direi che a rigor di logica dovrebbe dare gli stessi risultati anche quella. Secondo me dovresti controllare di avere l'ultima versione dlla 2.18 e come è impostato l'ellissoide nelle proprietà progetto (tab generale, sotto il gruppo misurazioni): settalo a none/planimetric o GRS180. Martina Il giorno sab 8 dic 2018 alle ore 22:22 Marco Spaziani < spaziani.ma...@gmail.com> ha scritto: > Basta. Ci rinuncio. Mi sono incartato. Io mi arrendo. Ho provato in tutti > i modi ma non ci riesco. > Se volete provarci voi vi propongo un test facile facile, tanto per capire > se sono io lo scemo del villaggio o se invece c'è qualcosa che non va. > Andate qui: > > http://dati.lazio.it/catalog/it/dataset/2014-carta-tecnica-regionale-numerica-scala-1-5-000-provincia-di-frosinone/resource/863936db-bcbd-429f-8b62-9986a1d1ab13 > e scaricatevi il raster 376042 impostato nel sistema di riferimento EPSG > 25833 e relativo alla CTR del 2014 > Poi andate qui: > > http://dati.lazio.it/catalog/it/dataset/carta-tecnica-regionale-2009-5k-frosinone/resource/f5c7cd76-9c1b-4cc3-86d1-75bfc3109353 > e scaricatevi l'analogo raster 376042 impostato nel sistema di riferimento > EPSG 3004 e relativo alla CTR del 2009. > Una volta scaricati, aprite un progetto in QGIS, impostate il SR che > volete, selezionate la "riproiezione al volo" e importate i due raster che > avete appena scaricato, (e che sono relativi alla stessa identica porzione > di territorio), quindi a uno dei due raster date un 50% di trasparenza e > vedete un po cosa vi viene fuori. > A me mi viene il solito spostamento di circa 3 m verso NW di uno rispetto > all'altro (per apprezzarlo zoomate alla scala 1:500 e guardate il sentiero > che passa vicino al confine della provincia/comune). > Vi ho proposto il raster 376042 perchè sono solo 4Mb di dati scaricare e > fate subito, ma il confronto lo potete fare con quello che volete, raster o > shape file che sia ...io le ho provate tutte, raster con raster, shape con > shape, raster con shape ... e sempre uno spostamento di circa 3 m mi viene. > Secondo voi dov'è il problema? sono io che non so usare il SR 25833? > ...è QGIS che non sa riproiettare il SR 25833? ...è il data set > cartografico della Regione che contiene cartografia bacata? > Fatemi sapere. > Grazie > > > > > Il giorno sab 8 dic 2018 alle ore 00:02 Martina Savarese < > martina.savar...@gmail.com> ha scritto: > >> Sono la stessa cosa in due lingue diverse (in parole poverissime) >> QGS usa proj4, la specifica che trovi nel file prj è esri wkt. Se vai su >> epsg.io e fai la ricerca di un qualsiasi epsg in fondo alla pagina trovi >> (mi pare sia sotto la voce esporta, ma ora non ho il computer sotto mano) >> la possibilità di esprimere quel epsg in vari formati; cliccali uno per uno >> e vedi in quanti modi si può dire secondo in cosa stai lavorando >> >> Martina >> >> Il giorno Ven 7 Dic 2018 23:28 Marco Spaziani >> ha scritto: >> >>> In realtà la stringa contenuta nel file PRJ degli shape file è un po' >>> più "lunga" di quella che hai suggerito tu e, precisamente, è: >>> >>> >>> PROJCS["ETRS_1989_UTM_Zone_33N",GEOGCS["GCS_ETRS_1989",DATUM["D_ETRS_1989",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",50.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",15.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]] >>> >>> Nell'elenco dei SR di QGIS 2.18 LTR, il SR è esplicitato con la seguente >>> "semplice" stringa: >>> >>> +proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs >>> >>> *(che comunque, per quanto semplice, coincide con quella indicata nel >>> sito ufficiale dell'EPSG)* >>> >>> >>> Chi tra voi ha padronanza con i SR "personalizzati" ...mi sa spiegare >>>
