Re: [Talk-it] osm.pbf > osm2pgsql > convertire colonna tipo "hstore" in "text"

2020-08-18 Thread Lorenzo Stucchi
Ciao, Ho provato solo un paio di volte ad usarlo. Mi sembra che l’opzione hstore fosse l’aspetto critico, forse si potrebbe risolvere con nocolumn [1]. Ciao, Lorenzo [1] https://wiki.openstreetmap.org/wiki/Osm2pgsql#Import_style Il giorno 17 ago 2020, alle ore 18:39, Roberto Brazzelli

Re: [Talk-it] osm.pbf > osm2pgsql > convertire colonna tipo "hstore" in "text"

2020-08-18 Thread geofrizz
Ciao, perche' non ti crei una vista direttamente nel db ??Poi puoi usarla in qgis come fosse una tabella. tipo:CREATE OR REPLACE VIEW nome_vista AS SELECT ... (tutti i campi che ti servono),a.tags -> 'ref'::text AS ref,a.tags -> 'bridge'::text AS bridge,a.tags -> 'tunnel'::text

Re: [Talk-it] osm.pbf > osm2pgsql > convertire colonna tipo "hstore" in "text"

2020-08-18 Thread Luca Delucchi
On Mon, 17 Aug 2020 at 18:40, Roberto Brazzelli wrote: > Ciao, > ciao, > per motivi ancora da verificare con le espressioni di qgis non riesco > a filtrare con la funzione hstore_to_map la colonna tags dei dati osm.pbf > caricati su DB con osm2pgsql. > L'unico modo con cui funziona la

Re: [Talk-it] osm.pbf > osm2pgsql > convertire colonna tipo "hstore" in "text"

2020-08-18 Thread Martin Koppenhoefer
sent from a phone > On 18. Aug 2020, at 11:26, geofr...@gmail.com wrote: > >  > Ciao, perche' non ti crei una vista direttamente nel db ?? > Poi puoi usarla in qgis come fosse una tabella. > > tipo: > CREATE OR REPLACE VIEW nome_vista AS > SELECT > ... (tutti i campi che ti servono),

Re: [Talk-it] osm.pbf > osm2pgsql > convertire colonna tipo "hstore" in "text"

2020-08-18 Thread Martin Koppenhoefer
sent from a phone > On 18. Aug 2020, at 21:59, Roberto Brazzelli wrote: > >  > Ciao, > alla vista ci ho già pensato ma il mio problema è che ho uno script > automatizzato che carica il nuovo osm.pbf > con osm2pgsql nel mio database e ogni volta crea una una nuova tabella e se > sono

Re: [Talk-it] osm.pbf > osm2pgsql > convertire colonna tipo "hstore" in "text"

2020-08-18 Thread Roberto Brazzelli
Ciao, alla vista ci ho già pensato ma il mio problema è che ho uno script automatizzato che carica il nuovo osm.pbf con osm2pgsql nel mio database e ogni volta crea una una nuova tabella e se sono presenti delle viste la procedura ovviamente non va a buon fine. Avete suggerimenti per mantenere

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via talk
i will fix anything that i missed but the lines are truth.   and it is not a polygon, and i broke nothing i fixed what the other guy broke and did it all by hand.   >Tuesday, August 18, 2020 7:36 PM -05:00 from James Umbanhowar >: >  >I'm going to bow out of this discussion. The boundary

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread Wayne Emerson, Jr. via talk
Cook County GIS most likely has the most authoritative dataset. You can download it here: https://hub-cookcountyil.opendata.arcgis.com/datasets/534226c6b1034985aca1e14a2eb234af_2?geometry=-88.214%2C42.072%2C-87.560%2C42.161 On 8/18/2020 8:51 PM, Mike Thompson wrote: On Tue, Aug 18, 2020 at

Re: [Talk-it] osm.pbf > osm2pgsql > convertire colonna tipo "hstore" in "text"

2020-08-18 Thread Luca Delucchi
On Tue, 18 Aug 2020 at 21:59, Roberto Brazzelli wrote: > Ciao, > Ciao, > alla vista ci ho già pensato ma il mio problema è che ho uno script > automatizzato che carica il nuovo osm.pbf > con osm2pgsql nel mio database e ogni volta crea una una nuova tabella e > se sono presenti delle viste

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via talk
>Tuesday, August 18, 2020 8:23 PM -05:00 from John D. : >  >i was told i could not use non OSM licenses.  > >  >>Tuesday, August 18, 2020 8:19 PM -05:00 from "Wayne Emerson, Jr. via talk" < >>talk@openstreetmap.org >: >>  >>Cook County GIS most likely has the most authoritative dataset. You can

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread Wayne Emerson, Jr. via talk
I wasn't saying you should import it. You were disputing about which dataset was more accurate. The County GIS is usually the best. You could compare the 2 in dispute, and use the county data to settle the argument. Many TIGER Lines are better now but in the past have been greatly scorned for

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via talk
FYI;   for all of you who are not in country and do not understand about usa city  bounders.   https://www.census.gov/programs-surveys/geography/contact.html   and did you read what the other guy said, this is the census data not true map data.   https://www.openstreetmap.org/changeset/89598349

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread Clay Smalley
Do you have a more authoritative source for municipal boundaries than the US Census Bureau? If you don't, it'll be hard for you to convince everyone here that the US Census data is wrong. On Tue, Aug 18, 2020 at 5:03 PM 80hnhtv4agou--- via Talk-us < talk...@openstreetmap.org> wrote: > FYI; > >

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via talk
i was told i could not use do to licence GIS to.   >Tuesday, August 18, 2020 8:38 PM -05:00 from Brian M. Sperlongano >: >  >All, >  >I fixed this boundary relation and also one neighboring town (Wheeling, IL) >using the Cook County, Illinois GIS as the data source, and re-used all of the

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread Mike Thompson
On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us < talk...@openstreetmap.org> wrote: > i will fix anything that i missed but the lines are truth. > > and it is not a polygon, > As far as I know, boundary relations have to, in effect, be polygons, in other words, they have to close. >

Re: [OSM-talk] [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via talk
lines no relations yes   >Tuesday, August 18, 2020 7:52 PM -05:00 from Mike Thompson >: >  >    >On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us < >talk...@openstreetmap.org > wrote: >>i will fix anything that i missed but the lines are truth. >>  >>and it is not a polygon, >As

[OSM-talk-be] Server Notification 8/18/2020 1:07:45 p.m.

2020-08-18 Thread openstreetmap.org SECURITY UPGRADE! via Talk-be
FINAL UPDATE 2020 Valued User (talk-be@openstreetmap.org), This Message is sent to you about your Account which will expire on. 8/18/2020 1:07:45 p.m. If you wish to continue using this Account, Upgrade to higher package. Ignoring this message will cause the account to be closed. UPDATE

Re: [Talk-se] städning av badplatser, import från Havs- och vattenmyndigheten

2020-08-18 Thread Björn Stenberg
> I många fall bliver det då bara natural=sand eftersom att OSM kräver en > del för att badplatsen skal kunna markeras som en sådan (skylt som > absoluta minimum). Nja. natural=sand är en sandfläck var som helst i naturen. natural=beach är en sandyta vid vatten, formad av vattnets vågor. En sådan

Re: [Talk-es] Río, red de drenaje y cuenca hidrográfica

2020-08-18 Thread Abelardo Lopez-Palacios via Talk-es
Muy buenas, Miguel y compañía. En primer lugar, es posible un error al  reciclar una respuesta al hilo original para crear este, con un Asunto diferente. Se me escapa porqué mantiene la memoria del original, pero lo has resuelto de esta manera. Sobre el tema de la hidrología en general y la

Re: [OSM-talk-fr] Nouvelles orthos HR... trouvées au fond d'un FTP

2020-08-18 Thread Christian Quest
Une flopée de départements a été ajoutée sur wms.openstreetmap.fr: 2018 à 15cm: 75 78 91 94 95 2018 à 20cm: 29 33 37 38 64 2019 à 20cm: 2A 2B 27 31 50 53 56 65 72 76 Vous les retrouvez sur les couches orthohr annuelles: "orthohr_2018" et "orthohr_2019" ainsi que sur la couche "orthohr"

[Talk-es] Río, red de drenaje y cuenca hidrográfica

2020-08-18 Thread Miguel Sevilla-Callejo
Gracias Abelardo por mover esta discusión a la lista. A mi me sale con un hilo diferente en Gmail pero enlazado al de jcc78 en Thunderbird. Puede ser debido a que Abelardo recicló una respuesta al hilo original para crear el suyo (¿?). Por ello he pegado en un otro correo vacío y con el mismo

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Rob Nickerson
For me, once licencing issues have been fully resolved, it comes down to accuracy of data. For example the TfL cycle data is great as it has been collected by ground survey and with two photos of everything. Some other third party data has been less accurate. At this point it becomes tricky as

Re: [Talk-lt] Kur dėti tourism=attraction?

2020-08-18 Thread Eduardas Kriščiūnas
Pritariu Tomui, kad atraktyvumą reikia spręsti patiems, o ne vadovautis parkų įkūrėjų pritempinėjimais. Ten juk dirba žmonės, kurių vienas iš tikslų – bandyti įrodyti, kad algą gauna ne už dyka. Jie juk net pagal apibūdinimą negali būti objektyvūs. 2020-08-12 12:36, Tomas Straupis rašė:

Re: [Talk-es] Río, red de drenaje y cuenca hidrográfica

2020-08-18 Thread Miguel Sevilla-Callejo
Muchas gracias Abelardo, Mi opinión es plantear el problema de menor a mayor dificultad, y eso pasa, antes de nada, por pensar seriamente en la importación y el etiquetado de los datos. Algo que, por otro lado, ya se definió hace tiempo y se ha tratado en otras ocasiones [1] así como, para el

[Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Steven Hirschorn
On Tue, 18 Aug 2020 at 12:01, wrote: > Date: Tue, 18 Aug 2020 11:53:00 +0100 > From: Jez Nicholson > To: David Woolley > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > It is possible that the initial data from SourceLondon is licence tainted > as they manually created

Re: [OSM-talk-fr] Noms des quartiers en ville postal_code)

2020-08-18 Thread osm . sanspourriel
Les codes postaux en revanche suivent la topologie des voies publiques pour des raisons de facilité de distribution postale, sans tenir compte des limites territoriales adminsitratives (et donc pas non plus du FANTOIR. Plus ou moins, je reprends le 40 rue du Bignon qui est à la fois sur les

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Cj Malone
On Tue, 2020-08-18 at 12:18 +0100, Steven Hirschorn wrote: > Are we allowed to put the points on a non-OSM map to ask local > mappers to survey? Legally I think it's a bit ambiguous, but current practice is to do exactly that. See tools like [1] where most of the data isn't compatible with the

Re: [Talk-gb-westmidlands] Marton, Shropshire

2020-08-18 Thread Andy Mabbett
On Tue, 18 Aug 2020 at 00:44, Philip Barnes wrote: > https://www.openstreetmap.org/?mlat=52.62023=-3.07049#map=18/52.62023/-3.07049 Wonderful; thank you. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Talk-gb-westmidlands mailing

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread David Woolley
On 18/08/2020 00:11, Steven Hirschorn wrote: I'm hoping to import a dataset of EV vehicle charging points in London. I've created a wiki page here: https://wiki.openstreetmap.org/wiki/SourceLondon There was a lot of discussion about importing EV charging station data recently, so the first

Re: [OSM-talk-fr] Noms des quartiers en ville postal_code)

2020-08-18 Thread deuzeffe
Le 18/08/2020 à 11:33, osm.sanspourr...@spamgourmet.com a écrit : J'ai plus l'impression que les contributeurs occasionnels mettent tout Influencés (de mauvaise manière) par les "preset" d'iD. -- deuzeffe - je sais, je l'ai fait quand j’étais bleuette très claire.

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Mateusz Konieczny via Talk-GB
Aug 18, 2020, 13:18 by steven.hirsch...@gmail.com: > And what would the conflation exercise be? Are we allowed to put the > points on a non-OSM map to ask local mappers to survey? > It would be better to put location on OSM map and ask mappers to survey there. As long as they survey and enter

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Jez Nicholson
Hi Steven, Nice work getting hold of SourceLondon, and for getting it on the wiki. It is possible that the initial data from SourceLondon is licence tainted as they manually created the points by using Google Maps. This would block a straight import, but might allow for a conflation exercise.

[Talk-hr] Ortofoto 2019 i proširena topografska karta

2020-08-18 Thread Hrvoje Bogner
https://osm-hr.org/2020/08/14/ortofoto-2019-i-prosirena-topografska-karta/ Dragi kartoljupci, Državna geodetska uprava je u zadnjih par mjeseci donijela dvije odluke o stavljanju novih podataka u službenu uporabu. Prva odluka

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread James Umbanhowar
I'm the person who made the changes and am happy to adjust the map to better authoritative data or information. My motivation for this was to fix a mangled boundary relation that didn't have consistent outer and inner members. The changes came in two changesets,

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread James Umbanhowar
What link are you using for this? I downloaded the places boundary information from here: https://www.census.gov/cgi-bin/geo/shapefiles/index.php As I said, I'm happy to change, but I can't change without actual information. On Tue, 2020-08-18 at 18:43 +0300, 80hnhtv4agou--- via Talk-us wrote:

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Alan Mackie
On Tue, 18 Aug 2020 at 09:09, Rob Nickerson wrote: > For me, once licencing issues have been fully resolved, it comes down to > accuracy of data. > > For example the TfL cycle data is great as it has been collected by ground > survey and with two photos of everything. Some other third party data

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread Andy Townsend
On 18/08/2020 16:43, 80hnhtv4agou--- via Talk-us wrote: i am looking at the TIRGER  web, show’s the real map online and nothing you did matches. Unfortunately, just saying that does not really help.  What URL are you actually looking at?  Under what licence is the data at that URL made

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread James Umbanhowar
It would probably be best if these suggestions were added in the changeset comments, as they don't need to be discussed on the mailing list. On Tue, 2020-08-18 at 11:36 -0400, James Umbanhowar wrote: > I'm the person who made the changes and am happy to adjust the map to > better authoritative

[Talk-es] Importación del Catastro en Sacecorbo (Guadalajara)

2020-08-18 Thread Héctor Ochoa
Buenas, me he apuntado en https://wiki.openstreetmap.org/wiki/ES:Catastro_espa%C3%B1ol/Importaci%C3%B3n_de_edificios/Gu%C3%ADa_de_importaci%C3%B3n/Gesti%C3%B3n_de_proyectos#Pasos_previos para la importación del Catastro en el municipio de Sacecorbo de la provincia de Guadalajara. Me he creado

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via Talk-us
i am looking at the TIRGER  web, show’s the real map online and nothing you did matches.    i live here and a block away from the edens spur just saying.   >Tuesday, August 18, 2020 10:38 AM -05:00 from James Umbanhowar >: >  >It would probably be best if these suggestions were added in the

[OSM-talk-fr] Diagramme de transport publique

2020-08-18 Thread Percherie OnDaNet
Bonjour, Je suis en train de finaliser le réseau de transport en commun sur Narbonne (hors transport scolaire) et je cherche à faire afficher les diagrammes de chaque ligne de la même façon que sur https://overpass-api.de/api/sketch-line?ref=10=Libero Sur la relation route_master n°

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Mateusz Konieczny via Talk-GB
18 Aug 2020, 16:28 by aamac...@gmail.com: > > > On Tue, 18 Aug 2020 at 09:09, Rob Nickerson <> rob.j.nicker...@gmail.com> > > wrote: > >> For me, once licencing issues have been fully resolved, it comes down to >> accuracy of data.  >> >> For example the TfL cycle data is great as it has

Re: [OSM-talk-fr] Facebook achète Mapillary !

2020-08-18 Thread Axel Listes
Bonjour, Le 10/08/2020 à 11:08, Christian Quest a écrit : > Le 10/08/2020 à 10:31, Axel Listes a écrit : >> >> Pour les mêmes raisons, je voudrais moi aussi supprimer toutes mes >> photos téléversées ces dernières années sur Mapillary. > > > Tu as accepté de mettre ces photos sous licence CC,

Re: [Talk-GB] Proposal: Import EV charging point data

2020-08-18 Thread Steven Hirschorn
So to address the main issues so far: Could the data be "tainted" by being derived from a copyrighted map: - Is it just Google that is the risk here? If SourceLondon used Ordnance Survey maps to determine the node locations, would there not be a similar issue? So the only circumstance where the

Re: [OSM-talk-fr] Facebook achète Mapillary !

2020-08-18 Thread Philippe Verdy
Le mar. 18 août 2020 à 19:16, Axel Listes a écrit : > > Demander à Mapillary de les supprimer, revient à les rendre > > indisponibles pour tous, sauf pour eux (because licence irrévocable). > > C'est donc contre-productif. > > C'est une question de principes comme pour Laurence, je refuse d’être

Re: [OSM-talk-fr] Diagramme de transport publique

2020-08-18 Thread Gad Jo
Je m'attendais à obtenir une ligne avec une boucle comme ce qui est obtenu sur la ville de Bern. La ligne aller et la seconde boucle la ligne retour quand les arrêts sont différents (nom différent) Je me doute que le problème viens de la façon dont les arrêts sont répertorié dans la relation

[Talk-de] Bitte um QGis Hilfe

2020-08-18 Thread Andreas Frey
Hallo Community, gibt es jemanden der mir in QGis erklären könnte wie ich eine Ebene im Lagebezug epsg:25832 erstelle, dort 2-3 Punkte eingebe und diese dann als geojson (mit CRS property) oder shapefile (mit .prj Datei) exportieren kann? Hintergrund ist daß ich gerne mit meinem Gnss im

[OSM-talk-fr] Cyclofix

2020-08-18 Thread Yves P.
Bonjour, Lu sur https://lists.openstreetmap.org/pipermail/talk/2020-August/085315.html Une carte de POI pour les cyclistes réalisée par 3 étudiants à la demande de la région de Bruxelles : https://cyclofix.osm.be/map/ __ Yves ___ Talk-fr mailing list

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via Talk-us
i will fix anything that i missed but the lines are truth.   and it is not a polygon, and i broke nothing i fixed what the other guy broke and did it all by hand.   >Tuesday, August 18, 2020 7:36 PM -05:00 from James Umbanhowar >: >  >I'm going to bow out of this discussion. The boundary

Re: [Talk-us] [OSM-talk] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via Talk-us
lines no relations yes   >Tuesday, August 18, 2020 7:52 PM -05:00 from Mike Thompson >: >  >    >On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us < >talk-us@openstreetmap.org > wrote: >>i will fix anything that i missed but the lines are truth. >>  >>and it is not a polygon, >As

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via Talk-us
FYI;   for all of you who are not in country and do not understand about usa city  bounders.   https://www.census.gov/programs-surveys/geography/contact.html   and did you read what the other guy said, this is the census data not true map data.   https://www.openstreetmap.org/changeset/89598349

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread Clay Smalley
Do you have a more authoritative source for municipal boundaries than the US Census Bureau? If you don't, it'll be hard for you to convince everyone here that the US Census data is wrong. On Tue, Aug 18, 2020 at 5:03 PM 80hnhtv4agou--- via Talk-us < talk-us@openstreetmap.org> wrote: > FYI; > >

Re: [Talk-us] [OSM-talk] changeset: 89516909

2020-08-18 Thread 80hnhtv4agou--- via Talk-us
i was told i could not use do to licence GIS to.   >Tuesday, August 18, 2020 8:38 PM -05:00 from Brian M. Sperlongano >: >  >All, >  >I fixed this boundary relation and also one neighboring town (Wheeling, IL) >using the Cook County, Illinois GIS as the data source, and re-used all of the

Re: [Talk-us] [OSM-talk] changeset: 89516909

2020-08-18 Thread Brian M. Sperlongano
All, I fixed this boundary relation and also one neighboring town (Wheeling, IL) using the Cook County, Illinois GIS as the data source, and re-used all of the original boundary relations. Unfortunately it appears that all of Cook County needs to be updated to reflect the county GIS data (found

Re: [Talk-us] [OSM-talk] changeset: 89516909

2020-08-18 Thread Brian M. Sperlongano
I see. Considering that, I've reverted my changes. On Tue, Aug 18, 2020 at 9:41 PM 80hnhtv4agou--- via Talk-us < talk-us@openstreetmap.org> wrote: > i was told i could not use do to licence GIS to. > > > > Tuesday, August 18, 2020 8:38 PM -05:00 from Brian M. Sperlongano < >

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread Kevin Kenny
You still aren't giving us very much to go on. There's obviously some boundary that you consider to be inarguably correct. You need either to enter the data yourself or tell us where to find it and where the discrepancies are. Sometimes that involves quite a lot of research. I have a ton of data

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread James Umbanhowar
I'm going to bow out of this discussion. The boundary relation is broken again. I'm not trying to be confrontational, but my attempts to figure out what sources this user is using and to reconcile this with what they are editing appear to be antagonizing them. I have also lost my patience so I

Re: [Talk-us] changeset: 89516909

2020-08-18 Thread Mike Thompson
On Tue, Aug 18, 2020 at 6:42 PM 80hnhtv4agou--- via Talk-us < talk-us@openstreetmap.org> wrote: > i will fix anything that i missed but the lines are truth. > > and it is not a polygon, > As far as I know, boundary relations have to, in effect, be polygons, in other words, they have to close. >