Re: [talk-au] Use of map data with no copyright?

[Dion Moult]

It is also my understanding that lack of mention of a license means no license, 
which means copyrighted by default:

https://choosealicense.com/no-permission/

Dion Moult

 Original Message 
On 5 Oct. 2018, 12:17 pm, cleary wrote:

> It is my understanding that copyright exists whether or not there is a 
> copyright notice on a document/item.  Unless someone with more legal 
> knowledge has better information, I would say that copying is not permitted 
> unless we go through the usual permisison process.
>
> On Fri, Oct 5, 2018, at 11:56 AM, Graeme Fitzpatrick wrote:
>
>> Hi
>>
>> On holidays last week & went into the local tourist info centre.
>>
>> Picked up a map showing various food & accommodation attractions in the 
>> area, together with a fairly detailed map of the region.
>>
>> I've gone over the entire sheet of paper & there is not one mention of 
>> "copyright" anywhere on it!
>>
>> In that case, are we allowed to copy details?
>>
>> Thanks
>>
>> Graeme
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Use of map data with no copyright?

[cleary]

It is my understanding that copyright exists whether or not there is a
copyright notice on a document/item.  Unless someone with more legal
knowledge has better information, I would say that copying is not
permitted unless we go through the usual permisison process.


On Fri, Oct 5, 2018, at 11:56 AM, Graeme Fitzpatrick wrote:
> Hi
> 
> On holidays last week & went into the local tourist info centre.
> 
> Picked up a map showing various food & accommodation attractions in
> the area, together with a fairly detailed map of the region.> 
> I've gone over the entire sheet of paper & there is not one mention of
> "copyright" anywhere on it!> 
> In that case, are we allowed to copy details?
> 
> Thanks
> 
> Graeme
> _
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Use of map data with no copyright?

[Andrew Harvey]

Under the law, that map would be copyrighted regardless of if they
mention it's copyrighted or not.

It can be hard to work out where to draw the line, copying the name of
a street from the street sign is okay, but going over a large map and
systematically copying every street is not.

On Fri, 5 Oct 2018 at 11:57, Graeme Fitzpatrick  wrote:
>
> Hi
>
> On holidays last week & went into the local tourist info centre.
>
> Picked up a map showing various food & accommodation attractions in the area, 
> together with a fairly detailed map of the region.
>
> I've gone over the entire sheet of paper & there is not one mention of 
> "copyright" anywhere on it!
>
> In that case, are we allowed to copy details?
>
> Thanks
>
> Graeme
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Use of map data with no copyright?

[Warin]

On 05/10/18 11:56, Graeme Fitzpatrick wrote:

Hi

On holidays last week & went into the local tourist info centre.

Picked up a map showing various food & accommodation attractions in 
the area, together with a fairly detailed map of the region.


I've gone over the entire sheet of paper & there is not one mention of 
"copyright" anywhere on it!


In that case, are we allowed to copy details?




I would think so.

Where I have come across a sign carrying a map that has no copyright I 
have tended to use it.
If the thing has some form of contact then checking with them might be a 
belt and braces solution?
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Use of map data with no copyright?

[Graeme Fitzpatrick]

Hi

On holidays last week & went into the local tourist info centre.

Picked up a map showing various food & accommodation attractions in the
area, together with a fairly detailed map of the region.

I've gone over the entire sheet of paper & there is not one mention of
"copyright" anywhere on it!

In that case, are we allowed to copy details?

Thanks

Graeme
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] PSMA Administrative Boundaries

[cleary]

A month ago, we celebrated the news that OSM now has approval to use the
PSMA Administrative Boundaries and there was some discussion, including
the need for a proper import process.  I am willing to start adding some
boundaries in areas with which I am familiar/interested but I am waiting
for the proper import process to be determined. I am not aware if
anything has been done in regard to a plan to import this data. If so,
please guide me. If not, I propose the following:

Individual mappers download most recent data from
https://data.gov.au/dataset/psma-administrative-boundaries and add/check
data in their areas of interest and/or when they have time.  (Andrew
Harvey has provided a script to assist working with PSMA Administrative
Boundaries Data and there is a link on
https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogue)
Administrative boundaries in NSW, SA, VIC and ACT be modified instance-by-
instance if there are discrepancies that require updating. Where there
are discrepancies, the most recent data is usually preferred . If there
are concerns about accuracy of the most recent data, further
consultation with other mappers or relevant government boundary
authorities would be appropriate.
In QLD, WA, TAS and NT :  LGA and Suburb/Locality boundaries be added
one at a time, integrating with existing data where appropriate.
Previous data from unauthorised sources be deleted or the authorised
source be added if the data is accurate.
LGA Boundaries continue to be tagged as admin_level=6
Suburb/Locality boundaries be tagged as admin_level=10

In both instances source=PSMA_Admin_Boundaries_August_2018  
(or whichever date is applicable to the most recent data being used)
This source information may seem unwieldy but provides accuracy and
completeness of information.
Administrative boundaries NOT be attached to other ways such as creeks,
rivers, roads, etcetera so that the other features can be modified as
needed without affecting the administrative boundaries which are
generally static.
Multiple administrative boundaries (including national_parks and
government approved protected_areas or state forests) be mapped on a
single way, where appropriate, and with multiple relations attached
to that single way i.e. a single way could form the boundaries for
localities, LGAs and a national park, if appropriate in the
particular location.
Electoral boundaries NOT be added at this time.

Other boundaries which have been discussed, such as regions and
indigenous areas, NOT be added as part of this particular project unless
they are LGAs or Suburbs/Localities (some indigenous areas may be
identified as protected areas or defined localities or LGAs, in which
case they are added and identified on that basis). Mapping of regions
could be further discussed separately if required. They are usually not
defined by legislation and therefore usually not "administrative" in the
way that LGAs and Suburbs/Localities are legislated.

Comments and feedback, please.




On Fri, Aug 31, 2018, at 4:23 PM, Andrew Harvey wrote:
> The Department of Industry, Innovation and Science which manages
> data.gov.au have just completed the OSMF CC BY waiver allowing the
> PSMA Administrative Boundaries[1] to be used within OpenStreetMap[2].> 
> Quoting their email, "The Australian Government received great
> encouragement from PSMA Australia Limited to make the AB
> [Administrative Boundaries] data more accessible. Many thanks to OSM
> for your ongoing global open data efforts."> 
> Others more active in working with admin boundaries in OSM might be
> able to comment further on my analysis, but I've taken a look at the
> current OSM data from a planet extract[3], using osmium tool to
> extract administrative boundaries[4]:> 
> osmium tags-filter australia-latest.osm.pbf
> nwr/boundary=administrative -o osm-admin-boundaries.osm.pbf> 
> Then converted to GeoPackage to open in QGIS to compare to PSMA
> boundaries:> 
> ogr2ogr -f GPKG osm-admin-boundaries.gpkg osm-admin-
> boundaries.osm.pbf> 
> The admin_level values for Australia are defined as[5]:
> 
> 3 n/a
> 4 State or Territory
> 5 n/a (but used in Victoria for regions[6])
> 6 Local Government Area (eg Shire/Council)
> 7 District or Region (e.g Perthshire, Fitzroy, Canning, Greater
> Sydney, Greater Melbourne, etc.)> 8 Postcode
> 9 Suburb and Locality
> 10 Suburb and Locality
> 
> (not sure why the split across 9 and 10...? but it looks like no
> data for 9 and all suburb/localities are marked as 10, a seperate
> discussion but perhaps they should be 9 and smaller neighbourhoods
> be in 10?)> 
> PSMA Admin Boundaries provide (for Australia wide Shapefiles see [7]
> built from [8])> 
> Commonwealth Electoral Boundaries (I don't think should be
> included in OSM)> State Electoral Boundaries (I don't think should be 
> included in OSM)
> State Boundaries
> Local Government Areas
> Suburbs / Localities
> Town Points
> Wards
> 
> admin_level 6 LGAs
> It looks like NSW, VIC 

[OSM-talk] LinuxFoundation Energy Summit 2018 in Edinburgh (too few OSM inside)

[François Lacombe]

Hi all,

Recently some power grid operators join their efforts to build up strong
open source software designed for energy grid building and operating.
It's mainly intended for professionals, engineers, researchers...

The next LinuxFoundation Energy Summit will be held by next 24 October.
https://events.linuxfoundation.org/events/lfenergysummit2018/

Collaborative cartography may be really important to achieve development of
such complex systems: they need accurate and up to date data.
Following my current professional experience, it becomes more and more
usual to clean-up proprietary and inside dataset with OSM data (my job,
sometimes on power infrastructure)
Certainly thanks to the long time effort of the community.
I wouldn't be surprised to see some French DSOs (distribution grids)
updating part of their own GIS with OSM.

Wouldn't it be time to show up in such professional events?
OSMF should think about OSM representation in LinuxFoundation events,
shouldn't it?


All the best

*François*
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-GB] Ban on putting Shetland in a box on maps*

[Dave F]

If you're working for a Scottish public authority & producing static 
maps, best be aware:


https://www.bbc.co.uk/news/uk-scotland-scotland-politics-45733111

*There is a cop out clause.

Cheers
DaveF

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] nomi vie con numeri romani

[Cascafico Giovanni]

Io sarei per il maiuscolo, quando si tratta di date ricorrenti con
significato speciale

Piazza Primo Maggio
Via Venti Settembre
ecc.

Il gio 4 ott 2018, 20:17 Damjan Gerl  ha scritto:

> Si concordo, quindi io metterei:
>
> name=Via venticinque aprile
> +alt_name=Via XXV aprile
> +short_name=Via 25 aprile
>
> cosi da prevedere tutte le varianti per la ricerca.
>
> Ciao
> Damjan
>
> 04.10.2018 - 17:42 - Andrea Musuruane:
>
> Ciao,
>
>
> On Thu, Oct 4, 2018 at 5:34 PM demon.box  wrote:
>
>> ciao, scusate, l'argomento lo sò che è già stato affrontato in passato,
>> ma ho
>> trovato discussioni molto vecchie perciò preferisco richiedere.
>>
>> i nomi delle vie che contengono numeri romani come li carichiamo?
>>
>> Esempio "Via XXV Aprile"
>>
>> la carico così come è scritta sul cartello (visto che spesso si trova
>> scritto anche "Via 25 Aprile") oppure traduciamo sempre in "Via 25 Aprile"
>> oppure traduciamo sempre in "Via XXV Aprile"?
>> che dite?
>>
>
> Le regole ISTAT, che i comuni devono seguire per dare i nomi alle aree di
> circolazione sono le seguenti:
>
>- Le aree di circolazioni che riportano date complete, si inseriscono
>utilizzando la la numerazione naturale (1, 2, 3, ecc.) per i giorni e per
>l'anno, e il mese con caratteri alfabetici (gennaio, febbraio, ecc.). Es.
>Via 18 agosto 1944.
>- Le aree di circolazione che riportano date composte solo da giorni e
>mese, si inseriscono esplicitando il giorno in lettere. Es: Via venticinque
>aprile.
>
> Mi rendo conto che pochi comuni lo stiano già facendo e molte strade hanno
> ancora cartelli con dizioni differenti. Tra l'altro, se ben ricordo, i
> comuni non hanno l'obbligo di adeguare i cartelli stradali. Quindi magari
> nello stradario (e sulle carte di identità) sono riportate con la dizione
> corretta.
>
> Detto questo, avevamo concordato che seguivamo le regole ISTAT, anche per
> evitare che ognuno inserisse le date in modo differente (non sono rari
> anche casi dove la stessa strada ha grafie diverse sui vari cartelli).
>
> Era inoltre stato proposto di usare il tag alt_name per inserire altre
> grafie (es Via XXV aprile) in modo che un motore di ricerca potesse
> trovarle.
>
> Ciao,
>
> Andrea
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] grèves Loire

[François Boucault]

Bonsoir,

J'ai bien reçu le message d'Ades222, me parlant de votre discussion à
propos des grèves de la Loire...

Je viens de lire votre conversation, et je me réjouit que d'autres
personnes, avec un plus d'expériences dans OSM, s'approprient le sujet.
C'est vrai que pour tagguer cela c'était un peu compliqué, et vous
trouverez surement mieux que moi les tags appropriés. (le tag "seasonal"
me semble par exemple très bien indiqué)

Pourquoi j'ai commencé à cartographier ces zones ? Habitant du coin, et
amoureux des cartes, j'ai trouvé qu'une carte qui se veut un peu
représentative de la géographie ne pouvait pas passer à côté de ces
grèves, qui sont visibles la moitié de l'année et ne constituent pas
qu'un détail dans les paysages de Loire !

J'avoue que j'ai surtout recherché le tag qui permettait le meilleur
rendu possible, car c'était pas préoccupation à ce moment : une
cartographie parlante pour l'oeil, qui exprimerait bien le caractère
éphémère, mais présent ou sous-jacent. (si vous regardez les cartes IGN,
sur géoportail.gouv.fr, je trouve que leur rendu est intéressant par
exemple)

À propos de l'inexactitude, j'en avais parfaitement conscience en
dessinant les contours de ces bancs de Loire, mais pour côtoyer
quotidiennement ces lieux, je sais que ça ne bouge pas tant
annuellement... Par contre avoir des traits assez précis permettent au
moins de bien rendre compte du style de contours visibles dans la réalité.

Je confirme que les moniteurs de kayak disent que la baignade est
interdite durant la ballade sur la Loire, mais qu'il ne peuvent pas nous
empêcher de "tomber malencontreusement à l'eau"... ;-)

Je vais m'abonner à la mailist pour suivre les mails et pouvoir
continuer à discuter avec vous.

à plus,

bolikahult




0xC182EF00E01AF0D6.asc
Description: application/pgp-keys
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] nomi vie con numeri romani

[Damjan Gerl]

  
  
Si concordo, quindi io metterei:
  
  name=Via venticinque aprile
  +alt_name=Via XXV aprile
  +short_name=Via 25 aprile
  
  cosi da prevedere tutte le varianti per la ricerca.
  
  Ciao
  Damjan
  
  04.10.2018 - 17:42 - Andrea Musuruane:


  
  
Ciao,




  On Thu, Oct 4, 2018 at 5:34 PM demon.box  wrote:
  
  ciao,
scusate, l'argomento lo sò che è già stato affrontato in
passato, ma ho
trovato discussioni molto vecchie perciò preferisco
richiedere.

i nomi delle vie che contengono numeri romani come li
carichiamo?

Esempio "Via XXV Aprile"

la carico così come è scritta sul cartello (visto che spesso
si trova
scritto anche "Via 25 Aprile") oppure traduciamo sempre in
"Via 25 Aprile"
oppure traduciamo sempre in "Via XXV Aprile"?
che dite?
  
  
  
  Le regole ISTAT, che i comuni devono seguire per dare i
nomi alle aree di circolazione sono le seguenti:

  Le aree di circolazioni che riportano date complete,
si inseriscono utilizzando la la numerazione naturale
(1, 2, 3, ecc.) per i giorni e per l'anno, e il mese con
caratteri alfabetici (gennaio, febbraio, ecc.). Es. Via
18 agosto 1944.
  Le aree di circolazione che riportano date composte
solo da giorni e mese, si inseriscono esplicitando il
giorno in lettere. Es: Via venticinque aprile. 
  

  
  Mi rendo conto che pochi comuni lo stiano già facendo e
molte strade hanno ancora cartelli con dizioni differenti.
Tra l'altro, se ben ricordo, i comuni non hanno l'obbligo di
adeguare i cartelli stradali. Quindi magari nello stradario
(e sulle carte di identità) sono riportate con la dizione
corretta.
  
  
  
  Detto questo, avevamo concordato che seguivamo le regole
ISTAT, anche per evitare che ognuno inserisse le date in
modo differente (non sono rari anche casi dove la stessa
strada ha grafie diverse sui vari cartelli). 
  
  
  
  Era inoltre stato proposto di usare il tag alt_name per
inserire altre grafie (es Via XXV aprile) in modo che un
motore di ricerca potesse trovarle.
  
  
  
  Ciao,
  
  
  Andrea
  

  


  


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-ja] 住所 (was: Re: ローマ字)

[Leo Gaspard]

muramoto様、皆様

On 08/05/2018 08:33 PM, Leo Gaspard wrote:
>> ＞place=city_block, admin_level=11
>> 日本のタグ体系を大きく変更する提案になるので、多くの人のご意見を待ちたいと思います。
> 
> 他の人は意見ありますか。例えば、Google
> Mapsは番地の地図の機能を具備します[1]から、同じく番地の地図をOSMにも作りたいです。住所を検索できるために。

二ヶ月で誰も反対意見ではなさそうですから、ウィキを直そうと思います。ですけれども、私の日本語は良くないですから、日本人の人にやって頂けませんか。

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[Talk-cz] Znovu poštovní schránky v Brně, prosba o pomoc místních

[majka]

Do dat jsem právě nahrála další změnu
 , týkající se toho
přečíslování schránek v Brně.

Tím, že jsem opravila ta stará čísla schránek na nová, nám v datech
vyskákaly duplicity.
Pokusila jsem se je teď odstranit. V datech jsou nyní* schránky s ref
60010:000* *a/nebo s old_ref*, kde je to číslo původní. Je u nich i fixme
tag a note s původní adresou, pokud se mi v datech od 07/2018 podařilo tu
schránku pod starým číslem dohledat. U poměrně dost schránek mám však
podezření, že ty schránky už delší dobu nemusí fungovat.
Také tam přibylo několik přečíslovaných schránek, kde se ale změnil i ten
popis od České pošty. Pokud se s větší jistotou dalo určit, že je to stejná
schránka, je tam nové číslo uvedené ale u schránky zůstává jak tag old_ref,
tak i fixme s textem "2018/10 změněna čísla ref, zde změna i u adresy".
*Prosím*, zda by místní nebo na místě se vyskytující mohli *zkontrolovat
všechny tyhle schránky s tagem fixme začínajícím na "2018/10 změněna čísla
ref"*, a příslušně zareagovat podle situace na místě - tj. případně zrušené
schránky kompletně vymazat, u schránek, kde jen potvrdí správnost toho
přečíslování pak vymažou ten fixme tag, případně i old_ref, které by nadále
nemělo být zapotřebí. U zbytku schránek je pak třeba doplnit nové číslo a
opět vymazat fixme tag.
Celá tahle sranda se momentálně týká 68 schránek.

Díky všem,

Majka
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] nomi vie con numeri romani

[Andrea Musuruane]

Ciao,


On Thu, Oct 4, 2018 at 5:34 PM demon.box  wrote:

> ciao, scusate, l'argomento lo sò che è già stato affrontato in passato, ma
> ho
> trovato discussioni molto vecchie perciò preferisco richiedere.
>
> i nomi delle vie che contengono numeri romani come li carichiamo?
>
> Esempio "Via XXV Aprile"
>
> la carico così come è scritta sul cartello (visto che spesso si trova
> scritto anche "Via 25 Aprile") oppure traduciamo sempre in "Via 25 Aprile"
> oppure traduciamo sempre in "Via XXV Aprile"?
> che dite?
>

Le regole ISTAT, che i comuni devono seguire per dare i nomi alle aree di
circolazione sono le seguenti:

   - Le aree di circolazioni che riportano date complete, si inseriscono
   utilizzando la la numerazione naturale (1, 2, 3, ecc.) per i giorni e per
   l'anno, e il mese con caratteri alfabetici (gennaio, febbraio, ecc.). Es.
   Via 18 agosto 1944.
   - Le aree di circolazione che riportano date composte solo da giorni e
   mese, si inseriscono esplicitando il giorno in lettere. Es: Via venticinque
   aprile.

Mi rendo conto che pochi comuni lo stiano già facendo e molte strade hanno
ancora cartelli con dizioni differenti. Tra l'altro, se ben ricordo, i
comuni non hanno l'obbligo di adeguare i cartelli stradali. Quindi magari
nello stradario (e sulle carte di identità) sono riportate con la dizione
corretta.

Detto questo, avevamo concordato che seguivamo le regole ISTAT, anche per
evitare che ognuno inserisse le date in modo differente (non sono rari
anche casi dove la stessa strada ha grafie diverse sui vari cartelli).

Era inoltre stato proposto di usare il tag alt_name per inserire altre
grafie (es Via XXV aprile) in modo che un motore di ricerca potesse
trovarle.

Ciao,

Andrea
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] nomi vie con numeri romani

[demon.box]

ciao, scusate, l'argomento lo sò che è già stato affrontato in passato, ma ho
trovato discussioni molto vecchie perciò preferisco richiedere.

i nomi delle vie che contengono numeri romani come li carichiamo?

Esempio "Via XXV Aprile"

la carico così come è scritta sul cartello (visto che spesso si trova
scritto anche "Via 25 Aprile") oppure traduciamo sempre in "Via 25 Aprile"
oppure traduciamo sempre in "Via XXV Aprile"?
che dite?

grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] weird "excessive bounces" warnings from the list

[David Earl]

Lots of OSM email list mail ends up in my GMail spam. AFAICS this is
because the remailer doesn't deal with DKIM headers properly (it changes
the signed content, To: for example, so the signature test fails) and some
providers (btmail for example) have DMARC records which force the rejection
of such emails by the recipient, and even if they don't the dkim failure
can increase the spam score over the threshold. The envelope-from seems to
be correct so that it sees osm as the sender (even though that's not what
From: says) and so uses OSM's SPF correctly.

David

On Tue, 2 Oct 2018 at 07:05, Tom Hughes  wrote:

> On 02/10/2018 04:21, Paul Johnson wrote:
>
> > Only if the sender is sending from a server other than their normal mail
> > server, something readily detectable in the headers.  Google seems to
> > use the same strategy as I did running my own mail server for about 12
> > years before moving to gsuite, which is, hey, not totally
> > standards-compliant, since it'll go through DATA before deciding whether
> > or not to accept or reject, but very workable to give the sender some
> > idea what happened.
>
> Once it has gone through the list it appears to be being sent from
> our mail server.
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-ie] Irish Border Crossing points

[Keith]

Hi all,

Just a quick question, I was looking to get all the crossing points 
along the 'Irish' border.


Most of them seem to be mapped with node  ( name="Border NI/ROI" ) which 
is good

https://overpass-turbo.eu/s/CvI

Others are not tagged at all, or tagged with slight variation so I was 
going to edit these to match, no problem.
My concern is that others are tagged differently eg name="N1/A1 Border 
Crossing", so I am not too sure what to do here, is it best to have 
these be consistent, or should this consistency be based on type rather 
than name ?


Just wondering what you thoughts are.

Regards,

keith

PS

On a related note, I created this video composed from 17,117 satellite 
images tracing the path of the border as extracted from OSM.


https://www.youtube.com/watch?v=kCd9b0hiio0




___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-cz] OsmHiCheck - GPX export - novinky

[Tom Ka]

Ahoj,

udelal jsem drobnou upravu GPX exportu v OsmHiCheck - nove se do
popisu generuje info co je spatne (have/no img, have/no ref,
tourism=info only) a info o id OSM uzlu je jako link na osm.org, takze
se da jednoduse podivat, co je tam presne zadane.

Bye

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSRM-talk] OSRM aggregate steps too much

[François Lacombe]

Hi,

Regarding the situation below, I've upgraded to v5.19.0 to try to get a
more descriptive response from osrm-routed.
Classes has been added to ways and differ at the point where steps are
expected to split.

Nevertheless I still get a single step merging 3 different ways with
different classes, speed and weight.

It's important for me to distinguish different geometries with really
different data attached to them.
The step lengths 300m and merge 3 segments of 200m, 80cm and 99m.

The merge is occurring in the result only and the graph actually have the 3
independent geometries.
Is there a threshold to set to prevent such a merge to occur at anytime
please?


All the best

François


Le lun. 27 août 2018 à 12:26, François Lacombe 
a écrit :

> Hi all,
>
> I recently find a situation where OSRM/route service doesn't make
> distinction between two different geometries of my routing graph.
> I get a single step as a combination of both geometries despite they
> haven't the same speed nor the same name attribute. Then I'm not able to
> make a good process of the answer.
> Can you explain why osrm doesn't give two steps for this particular case
> please?
>
> The route :
> https://imgur.com/a/LE3xIg3
>
> The geometry :
> https://imgur.com/a/O109GG4
>
> Debug view :
> https://imgur.com/a/IdXokbt
>
> The route service response, the first step should stop at point 6 :
> First step actually stops at the end of D999 road.
> https://imgur.com/a/IdXokb
>
> I can give any more detail if needed, all the best
>
> François Lacombe
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSM-talk-be] osm - arlon - training course / evangelization

[Pierre Parmentier]

For your information.

I shall deliver some information at the Espace public numérique (EPN)
d'Arlon  about OpenStreetMap. In
French.

   - 23 October 2018 at 9.00*: Consulter OpenStreetMap*
   - 23 October 2018, at 13.00: *Consulter OpenStreetMap* (same subject)
   - 6 November 2018 at 9.00: *Contribuer à OpenStreetMap*
   - *27 *November 2018 at 9.00: *Contribuer à OpenStreetMap*

Reg
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-gb-westmidlands] October Meeting

[Rob Nickerson]

Great. See you later :-)

On Tue, 2 Oct 2018, 15:40 Ian Caldwell, 
wrote:

> I hope to be there.
>
> Ian
>
>
> On Sun, 30 Sep 2018 at 21:44, Rob Nickerson 
> wrote:
>
>> Great. See you there (back at our usual: The Bull, Price Street).
>>
>> *Rob*
>>
>>
>> On Sun, 30 Sep 2018 at 20:36, Eike Ritter  wrote:
>>
>>> Dear all,
>>>
>>> > I can make it. We're back in Birmingham for Winter. As I will need to
>>> > travel in, I will only do so if others are confirmed as attending. Hope
>>> > to see a few of you there.
>>> >
>>>
>>> I will be there.
>>>
>>> Best wishes,
>>>
>>> Eike
>>>
>>> ___
>>> Talk-gb-westmidlands mailing list
>>> Talk-gb-westmidlands@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>>
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-br] Autorização de uso de camadas de informações do Exército Brasileiro

[Sérgio V .]

Ótima notícia!! Valeu Érico!
Agradecimento especial à gentileza do Exército Brasileiro, em especial à 
Diretoria de Serviço Geográfico, em responder e esclarecer nossas necessidades 
de informações.

De minha parte, entendo que o ponto principal que a comunicação do Exército 
está dizendo é o seguinte:

O OSM está formalmente autorizado a usar como imagem de background as cartas 
topográficas matriciais do BDGEx e mapear sobre elas.
Eventualmente a autorização de uso pode ser revogada da parte do Exército por 
quaisquer razões (nesse caso, não seria mais permitido visualizar e mapear 
sobre os referidos materiais.)
No entanto, o que já tiver sido mapeado no OSM sobre estes materiais fica para 
sempre garantido para o OSM sob CCO, como afirmado da parte do Exército.

Por mim, entendo que:
-podemos adicionar à wiki a documentação;
-e o link para uso das imagens das cartas nos editores.

Obrigado Nelson.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Nelson A. de Oliveira 
Enviado: terça-feira, 2 de outubro de 2018 19:53
Para: OSM talk-br
Assunto: [Talk-br] Autorização de uso de camadas de informações do Exército 
Brasileiro

O Erico conseguiu autorização do Exército Brasileiro para uso de
alguns serviços disponíveis em
http://www.geoportal.eb.mil.br/portal/bdgex-1/servicos-ogc

Basicamente foi concedido o uso dessas camadas sob CC0 (compatível com
a ODbL https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility)

Partes importantes abaixo, documento completo em anexo.
Alguém tem alguma dúvida ou algo a acrescentar com relação a isso ou
podemos adicionar essa documentação na wiki do OSM
(https://wiki.openstreetmap.org/wiki/Contributors#Countrywide + link
pro PDF) e adicionar as camadas aos editores?

=
Protocolo: 60502001705201852
Data de Abertura: 13/09/2018 09:53
Orgão Superior: Destinatário MD – Ministério da Defesa
Orgão Vinculado: Destinatário CEX – Comando do Exército
Situação: Respondido
Status da Situação: Acesso Concedido (Resposta solicitada inserida no e-SIC)
Resumo: Autorização para uso de tiles da DSG

(...)
Levando em consideração o exposto até o momento, e que os
“tiles” do BDGEx ou as imagens geradas a cada requisição WMS
não possuem, ainda, um licenciamento próprio, parece razoável
considerar que seu uso pode ser regido pela licença CC0
(https://creativecommons.org/publicdomain/zero/1.0/legalcode), a
qual é compatível com a licença CC-BY-SA adotada no OSM.

Entretanto, convém salientar que esse licenciamento pode ser
alterado a qualquer momento, e que a comunidade OSM será
avisada, caso ocorra alguma alteração.
(...)
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-fr] grèves Loire

[ades]

J’ai indiqué ce fil au contribuyteur qui a dessiné les grèves autour des 
Pts-de-Cé.

J’avais parlé de l’interdiction de baignade parce que ‘natural:beach’, d’après 
le wiki induit sans vraiment le dire qu’il y a baignade.
La solution ‘natural:sand’ évite cette confusion. En plus l’interdiction de 
baignade est générale, pas liée aux grèves.


> Le 4 oct. 2018 à 04:36, osm.sanspourr...@spamgourmet.com a écrit :
> 
> On ne se vautre pas, on apprend ;-).
> 
> Sinon d'accord avec GarenKreiz et Marc Marc.
> Jean-Yvon
> 
> Le 03/10/2018 à 09:54, ades - ades_...@orange.fr  
> a écrit :
>> Merci pour les infos, surtout pour le tag ‘seasonnal’ que je n’avais pas 
>> encore repéré 
>> 
>> Si les grèves peuvent être se taggée par :
>> ‘natural:beach’ ; ‘surface:sand’ et ‘seasonal:summer’ ça me semble déjà 
>> beaucoup mieux. 
>> 
>> Pour éviter la confusion avec des plages destinées ou utilisées pour la 
>> baignade, il faudrait pouvoir indiquer que la baignade est interdite, sur 
>> l’objet plage ? ou sur le tracé du lit mineur ? sur les deux ? (baignade 
>> interdite dans la Loire et ses bras, en tout cas pour tout le dpt 49, arr. 
>> préf. de 1969 suite noyade de 19 enfants). 
>> 
>> En plus, entre la Daguenière et Montsoreau, il faudrait aussi tagger 
>> l’interdiction d’accès entre avril et août et les restrictions d'usage toute 
>> l’année (arrêté de  biotope du préfet de M-&-L) çà je ne sais pas faire ;-(
>> 
>> Ne faudrait-il pas  préciser dans le wiki que ‘wetland’ ne s’applique pas à 
>> ce qui est dans le lit mineur d’un fleuve ou d’une rivière ? 
>> 
>> 
>> Et en continuant de me vautrer ;-)… 
>> 
>> je reste quand même sceptique de l'intérêt de cartographier ces objets dans 
>> la partie non navigable de la Loire (amont de la Maine). Ça bouge tous le 
>> temps, même les années où il n’y a pas de nouvelle orthophoto… 
>> Pour la partie navigable (aval de l’embouchure de la Maine) la question est 
>> différente, les grèves sont stabilisée entre les épis noyés et donc tous les 
>> ans à la même place.
>> Si l’on cartographie les grèves pour la partie non navigable, quelle emprise 
>> leur donner ? et surtout comment maintenir l’information ? qui pourra faire 
>> une trace GNS de ces grèves tous les ans ? à quelle cote, -0,5 ? 0 ? +1 ? à 
>> quel moment ? comment on fait quand la grève se découvre pendant la période 
>> d’interdiction d’accès ?
>> 
>> 
>> 
>> 
>> 
>>> Le 2 oct. 2018 à 21:47, osm.sanspourr...@spamgourmet.com 
>>>  a écrit :
>>> 
>>> Tu parles de 
>>> https://www.openstreetmap.org/way/496482622#map=14/47.4216/-0.5124 
>>>  au 
>>> niveau d'Angers.
>>> Contrairement à ce que tu dis la description est presque exacte : il est 
>>> (mal) dit que le blanc s'érode, pas que le sable ou le gravier s'érode.
>>> Le phrasé est mauvais aussi dans cette partie puisque tu t'es vautré ;-).
>>> 
>>> Ça bouge tout le temps, oui. Je confirme je ne redessine pas les bancs de 
>>> sables par chez moi après chaque grande marrée. Non je ne suis pas à Anger 
>>> ;-).
>>> Et alors ? Une mise à jour de temps en temps ou pas, OK. Savoir qu'il y a 
>>> des blancs dans le coin, OK.
>>> 
>>> Pour moi un banc c'est au milieu de l'eau et une grève (ou plage suivant la 
>>> granulométrie) sur la rive. Mais je ne suis pas un marin d'eau douce. 
>>> Saumâtre c'est le minimum ;-).
>>> natural=sand ou shingle 
>>>  ou beach serait 
>>> plus juste.
>>> 
>>> intermittent=yes est faux.
>>> 
>>> seasonal <>=spring/summer/autumn/winter/wet_season/dry_season   
>>> serait plus adapté.
>>> 
>>> Jean-Yvon
>>> 
>>> 
>>> Le 02/10/2018 à 18:53, ades - ades_...@orange.fr 
>>>  a écrit :
 Je viens de « tomber » sur ça 
 :https://www.openstreetmap.org/query?lat=47.4187=-0.4896 
 
 dans le lit de la Loire figurent des zones tagguées : 
 natural : wetland
 Surface:sand
 Wetland :tidalflat
 intermittent:yes
 description: Les bancs (ou grèves) de sables sont constitués d'alluvions, 
 de sables ou de graviers déplacés par la rivière et s'érodant 
 progressivement. Régulièrement recouvert d'eau lors des crues, la 
 végétation n'a pas toujours le temps d'y prospérer.
 
 La description est bonne, le reste me semble être n’importe quoi 
 ;-).Enfin… pour la description,les alluvions,  sables et graviers, ça ne 
 s’érodent pas, c’est simplement mobile. Quant au ’temps de prospérer' de 
 la végétation c’est plus un jugement de valeur qu’autre chose, on 
 préférerait sans doute ‘le temps de s’y s’établir’…
 
 Ce n’est visible sur la BDOrtho que parce que l’IGN fait ses photos en 
 été. Soit à une cote (aux Ponts-de-Cé) d’environ -0,50 (environ 100 m3/s) 
 à la cote 0  (env. 

Re: [Talk-cz] problém se stahováním dlaždic LPIS

[majka]

On Thu, 4 Oct 2018 at 09:37, Marián Kyral  wrote:

> ...
>
> Ale i tak bych zkusil starší verzi JOSM, jestli to nerozbil ten upgrade.
>
> Včera jsem zkoušel starší verzi co mám (14270) a s ní to běhá. Ale už jsem
> se nedostal k tomu vyzkoušet nejnovější verzi.
>
Verzí JOSM to není, patrně se ty dlaždice ve skutečnosti poskytují z více
míst a jedno z nich má ten problém, nebo snad někde něco vázne na trase
konkrétního providera. Protože mě to celou dobu běží v pořádku, nezávisle
na verzi JOSM (stará, současná i nejnovější) - připojení z jižních Čech,
případně i přes proxy někde v Německu, JOSM běží pod Win. Na ten problém se
mi narazit zatím nikde nepodařilo, znám ho jen z jiných vrstev.

Majka
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] WeeklyOSM CZ 427

[Tom Ka]

Ahoj, je dostupné vydání 427 týdeníku WeeklyOSM:

http://www.weeklyosm.eu/cz/archives/10754

* Novinky a pravidla Fody.
* Aktuální mapa na osmap.cz.
* Kategorie SK mýta.
* Mapování bezpečnostních kamer.
* Blokování uživatelů OSM.
* Dort pro mappera.
* Tvorba map s MapTiler.
* Chyby silniční sítě.
* Locus na hodinkách.

Pěkné počtení ...

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk] Really heavy browser load with Overpass-turbo map display

[Nick Whitelegg]

I can also confirm that the lagginess of MapThePaths (UK site aimed at mapping 
footpaths), which first appeared in 62.0, has disappeared in 62.0.3.


It too uses a GeoJSON vector layer.


Nick



From: Dave F 
Sent: 03 October 2018 23:15:29
To: osm-talk
Subject: Re: [OSM-talk] Really heavy browser load with Overpass-turbo map 
display

It appears to have been fixed in FF v62.0.3 (64bit)

Cheers
DaveF

On 23/09/2018 21:55, François Lacombe wrote:
Hi Dave
Thanks for your input

Is Leaflet aware and will fix the issue?
Switching to an older version of a browser isn't neutral and raise security 
considerations as always.

I didn't find anything relative to this problem on Leaflet github

All the best

François

Le dim. 23 sept. 2018 à 21:13, Dave F 
mailto:davefoxfa...@btinternet.com>> a écrit :
It appears it maybe Leaflet &/or Firefox related. Reports are it doesn't occur 
in Chrome/IE.

If your turn off Firefox auto updates & install an older version (I used v60.0 
from FileHippo) it prevents it.

Cheers
DaveF

On 23/09/2018 17:41, François Lacombe wrote:
HI all,

It's been a few days that my browser bear a heavy load when running many 
queries like https://overpass-turbo.eu/s/yUw, with overpass turbo.

Was any change done on the frontend to get such a load on client side?

Tested on firefox 62 64bits

All the best

François



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Really heavy browser load with Overpass-turbo map display

[Nick Whitelegg]

As mentioned in the other thread, the problem appears to have gone away with 
Firefox 62.0.3.


Nick


From: Lester Caine 
Sent: 04 October 2018 08:47:18
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] Really heavy browser load with Overpass-turbo map 
display

On 24/09/2018 20:36, Dave F wrote:
>> Switching to an older version of a browser isn't neutral and raise
>> security considerations as always.
>
> Usability is the same & 61.0 works OK & is only 2 months old. Personally
> I wouldn't rely on browser security.

There are a number of problems resulting from the major surgery Firefox
recently went through which are only slowly getting fixed. It would have
been much more sensible to maintain the original build in parallel until
more of the core functions and disabled extensions were made functional
and compatible. I'm still struggling with the lack of Firebug as the
replacement has problems with font sizes at least on linux and does not
provide some of the nice features Firebug STILL provides on my
development machine.

--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] On en parle dans l'actu: floutage des prisons françaises

[Philippe Verdy]

Je n'ai rien dit concernant ce qui est dans OSM mais uniquement sur la mise
à disposition des images BDOrtho par OSM (les "CU" générales de la BD Ortho
ne sont pas applicables car elles demandent une utilisation non commerciale
des photos, ou sinon un usage strictement personnel, et OSM.org a du sans
doute recevoir une licence spécifique dont je n'ai pas le détail).
L'objet de la question c'était ces photos. Si elles étaient floutées, on
n'aurait pas tracvé dans OSM le détail de ce qui se trouve **à
l'intérieur** et on n'aurait que les enceintes et sinon les tracés
approximatifs des bâtiments du cadastre, on n'aurait rien de plus avec une
capture depuis l'extérieur (même si c'est visible de l'extérieur, les
arrêtés n'autorise que les prises de vue incidentelles pour un usage
personnel/familial mais pas une utilisation pour une redistribution plus
importante (l'arrêté concerne tous les capteurs, pas que les photos). On
n'aurait donc droit qu'aux traces GPS le long des enceintes sur la voie
publique.


Le jeu. 4 oct. 2018 à 10:11, François Lacombe  a
écrit :

> Bonjour
>
> Le jeu. 4 oct. 2018 à 08:22, Christian Quest  a
> écrit :
>
>> Donc... quel impact pour OSM ? AUCUN
>>
>
> +1, merci de ne rien supprimer par ailleurs.
>
>
>> Mettre ces zonages dans OSM ? ce ne serait qu'une recopie de données,
>> rien de vérifiable sur le terrain, je n'en vois vraiment pas l'utilité.
>>
> +1 d'autant que ce ne sont pas les enceintes physiques, qui elles peuvent
> apparaitre autant que faire se peut dans OSM comme ce qu'on a l'habitude de
> faire pour les périmètres militaires ou centrales nucléaires
> Rien n'interdit d'aller se balader avec un GPS le long de la cloture pour
> relever un gpx
>
>
> Bonne journée
>
> François
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-africa] OSMkilawiki #425 2018-09-04-2018-09-10

[weeklyteam]

Habari za OpenStreetMap, swala 425, sasa linapatikana kwenye mtandao katika 
lugha ya Kiswahili, kutupa muhtasari wa mambo yote yanayotokea katika ulimwengu 
wa OpenStreetMap: 

http://www.weeklyosm.eu/sw/archives/10709/

Furahia!

OSMkilawiki? 
uwe nani? https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
uwe wapi? 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [OSM-talk-fr] On en parle dans l'actu: floutage des prisons françaises

[François Lacombe]

Bonjour

Le jeu. 4 oct. 2018 à 08:22, Christian Quest  a
écrit :

> Donc... quel impact pour OSM ? AUCUN
>

+1, merci de ne rien supprimer par ailleurs.


> Mettre ces zonages dans OSM ? ce ne serait qu'une recopie de données, rien
> de vérifiable sur le terrain, je n'en vois vraiment pas l'utilité.
>
+1 d'autant que ce ne sont pas les enceintes physiques, qui elles peuvent
apparaitre autant que faire se peut dans OSM comme ce qu'on a l'habitude de
faire pour les périmètres militaires ou centrales nucléaires
Rien n'interdit d'aller se balader avec un GPS le long de la cloture pour
relever un gpx


Bonne journée

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Really heavy browser load with Overpass-turbo map display

[Lester Caine]

On 24/09/2018 20:36, Dave F wrote:
Switching to an older version of a browser isn't neutral and raise 
security considerations as always.


Usability is the same & 61.0 works OK & is only 2 months old. Personally 
I wouldn't rely on browser security.


There are a number of problems resulting from the major surgery Firefox 
recently went through which are only slowly getting fixed. It would have 
been much more sensible to maintain the original build in parallel until 
more of the core functions and disabled extensions were made functional 
and compatible. I'm still struggling with the lack of Firebug as the 
replacement has problems with font sizes at least on linux and does not 
provide some of the nice features Firebug STILL provides on my 
development machine.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-cz] problém se stahováním dlaždic LPIS

[Marián Kyral]

Ahoj,
-- Původní e-mail --
Od: Jan Martinec 
Komu: OpenStreetMap Czech Republic 
Datum: 4. 10. 2018 9:28:04
Předmět: Re: [Talk-cz] problém se stahováním dlaždic LPIS
"
Ahoj,



Kdo ty dlaždice poskytuje? Tohle vypadá, že je nějaký problém na tamním
serveru s certifikátem - pokud je to to, co jsem zrovna odeslal do nového
vlákna, tak to asi ze své strany nespravíš.



"



LPIS je od Min. zemědělství.


 
"




Ale i tak bych zkusil starší verzi JOSM, jestli to nerozbil ten upgrade.

"



Včera jsem zkoušel starší verzi co mám (14270) a s ní to běhá. Ale už jsem
se nedostal k tomu vyzkoušet nejnovější verzi.




Marián



"






Zdar,

HPM







Dne čt 4. 10. 2018 9:15 uživatel Zdeněk Pražák mailto:zpra...@seznam.cz)> napsal:

"

aktualizoval jsem JOSM na poslední verzi 14289

kdyz si stahuji dlazdice LPIS tak se mi na obrazovce objeví červený text o
chybě při stahování dlaždic - viz přiložený screen

Po kliknutí na pole se pole aktualizuje


co mám udělat pro odstranění červeného textu
Pražák
___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)
https://openstreetmap.cz/talkcz(https://openstreetmap.cz/talkcz)
"
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] problém se stahováním dlaždic LPIS

[Jan Martinec]

Ahoj,

Kdo ty dlaždice poskytuje? Tohle vypadá, že je nějaký problém na tamním
serveru s certifikátem - pokud je to to, co jsem zrovna odeslal do nového
vlákna, tak to asi ze své strany nespravíš.

Ale i tak bych zkusil starší verzi JOSM, jestli to nerozbil ten upgrade.

Zdar,
HPM


Dne čt 4. 10. 2018 9:15 uživatel Zdeněk Pražák  napsal:

> aktualizoval jsem JOSM na poslední verzi 14289
> kdyz si stahuji dlazdice LPIS tak se mi na obrazovce objeví červený text o
> chybě při stahování dlaždic - viz přiložený screen
> Po kliknutí na pole se pole aktualizuje
> co mám udělat pro odstranění červeného textu
> Pražák
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] nadcházející distrust certifikátů od Symantecu - dopad?

[Jan Martinec]

Ahoj,

za pár dní vypne Chrome podporu certifikátů CA patřících Symantecu -
připravuje se to cca rok:
https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html
, a ostatní správci CA trust rootů budou zřejmě následovat (Firefox,
Oracle s Javou, MS s .NETem etc.)

Co s tím my? Celkem nic, ale zaspal mj. katastr, takže pokud vám
přestane něco fungovat z tohoto směru - nevalidní certifikáty, problémy
s připojením etc. - poruga ném in vassyem aparátula:
https://www.hlidacstatu.cz/texty/ktere-statni-sluzby-se-riti-do-problemu/
; to by mohlo zajímat třeba lid tracerový.

(OSM weby mají povětšinou LetsEncrypt, co tak koukám - těch se to nijak
nedotkne)

Zdar,
Honza "Piškvor" Martinec
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] problém se stahováním dlaždic LPIS

[Zdeněk Pražák]

aktualizoval jsem JOSM na poslední verzi 14289

kdyz si stahuji dlazdice LPIS tak se mi na obrazovce objeví červený text o
chybě při stahování dlaždic - viz přiložený screen

Po kliknutí na pole se pole aktualizuje


co mám udělat pro odstranění červeného textu
Pražák___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] What is people's experience with OSM import software?

[Frederik Ramm]

Hi,

On 04.10.2018 00:20, Kevin Kenny wrote:
> The schema as given by 'osm2pgsql' has first-class relations only in the
> 'rels' table, which is one of the 'slim' tables. The maintainers
> deprecate using those in the strongest possible terms.

Well, "strongest possible terms" is perhaps not the most fitting summary
of https://github.com/openstreetmap/osm2pgsql/issues/230... as has been
said there, quite a few people "mis"use osm2pgsql in that fashion, and
if they ever were to introduce a breaking change you can simply stick
with the osm2pgsql that you have...

But answering your question about alternatives:

* I have successfully used imposm3 to populate planet-wide databases and
keep them current with diffs, and the overall performance was sligthly
better than osm2pgsql's (with imposm having some features that osm2pgsql
doesn't and vice versa), but what osm2pgsql does with its
planet_osm_rels table imposm does with a file-based database and I have
no idea how difficult it would be to establish your first-class relation
table.

* The "PG Snapshot" schema used by Osmosis provides an interesting
concept of an "action" table which is filled upon the application of a
diff and allows you to run arbitrary code on newly-added or modified
things in the course of an update. The performance of Osmosis is,
however, far worse than osm2pgsql or imposm in my experience, and the PG
Snapshot schema is probably much too close to "raw OSM" for a mainly
rendering use case.

* If I wanted to achieve what you describe, I would likely either modify
osm2pgsql to do what I want, or run stock osm2pgsql and devise a
*separate* process, likely based on (py)osmium, that extracts the
information I need from a planet file or diff, and somehow adds that to
my PostGIS database. That way, I would continue to be able to use
osm2pgsql for what it does best, and I could still add my special
processing on top. Since my special processing is likely to only need a
fraction of the data, and osmium is quite efficient at filtering, the
risk of running into performance issues should be limited.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] On en parle dans l'actu: floutage des prisons françaises

[Christian Quest]

Pour info, j'avais extrait les coordonnées depuis le PDF de légifrance
(arrêté de janvier 2017) et remis ça en geojson et shapefile sur
data.gouv.fr:
https://www.data.gouv.fr/fr/datasets/zones-interdites-a-la-prise-de-vue-aerienne/

Vu qu'il y a eu un arrêté complémentaire en octobre 2017, il va falloir que
je mette ça à jour.

Il s'agit bien des zones où la prise de vue photo ou cinéma est interdite,
et ce n'est pas notre cas.
A ma connaissance, rien ne nous empêche de cartographier ces zones.

Donc... quel impact pour OSM ? AUCUN

Mettre ces zonages dans OSM ? ce ne serait qu'une recopie de données, rien
de vérifiable sur le terrain, je n'en vois vraiment pas l'utilité.

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr