Re: [Talk-se] Fwd: [Okfn-se] interested in a nordic open geo/map data meetup in novermber

2016-08-16 Thread Erik Johansson
Kanske intressant, speciellt för att se hur Kartverket fungerar
jämfört med Lantmäteriet.

Hack4no äger rum i Hønefoss går av stapeln fre 28, lör 29 oktober,
http://www.hack4.no/pages/om-hack4no

Tåg Oslo-Hønefoss restid ca 1 timme 30 min. (205 kr)

On Wed, Aug 10, 2016 at 10:41 PM, Mattias Axell  wrote:
> Hej listan,
>
> Fick inbjudan nedan och tänker att det kan vara av intresse för flera här.
> Se korta (eller långa) meddelandet nedanför och svara gärna på Doodlen om
> det låter spännande! :)
>
> /Mattias
>
>  Forwarded Message 
> Subject: [Okfn-se] interested in a nordic open geo/map data meetup in
> novermber
> Date: Wed, 10 Aug 2016 21:27:43 +0200
> From: miska knapek 
> To: okfn...@lists.okfn.org , okfn...@lists.okfn.org
> , okfn...@lists.okfn.org ,
> okfn...@lists.okfn.org, Okfn Dk 
>
>
> Hey good open folks,
>
>
> Short version :
>
> A Nordic open geo & map data meetup/mini-conference is possible in parallel
> with Hack4no, the open cultural data hackathon, at the end of October, in
> Norway.
> (More details below, but a question first )
>
> But, we need to know how many people would be interested i coming, and how
> many might be interested in contributing to make the event happen ( more on
> the latter below too ).
> There'll be tracks on different aspects of open geo/map data, as well as
> workshops.
>
> PLEASE fill in the doodle poll below, mentioning whether you might be
> interested in coming, as well as whether you might consider coming and
> paying a small fee to cover some basic costs.
>
> http://doodle.com/poll/75su2kut2thkzddd
>
> PLEASE answer as soon as possible - the poll closes on Sunday.
>
>
>
>
>
>
>
>
>
>
>
> Longer version :
>
> Some open people have voiced interest in having an open map data event, and
> we've some preliminary interest from people who'd like to run workshops and
> whatnot.
>
> Kartverket, the mapping authority of Norway, the main organiser of Hack4No,
> has said they could be interested in hosting a open map data event in
> parallel with Hack4No.
>
> This is really nice of Kartverket, but to make it happen, we need to know
> how many people could be interested in coming, and whether they'd consider
> paying some small fee to cover some basic costs.
>
>
>
> Longer version - part Two
>
> If enough people are interested in attending, the next steps would be to
> organise some tracks for the event. There's an academic/education, business,
> civil society, etc… side to open map & geo data. it'd be great to have an
> open call, get suggestions for content, and organise these different tracks.
>
> ( We've already had some offers from the kind folks at Wikipedia, as well as
> some others like Søren Johanssen, to run workshops on new wikipedia mapping
> features, as well as open source mapping tools. ( Of course, depending on
> how things go, it might or might not be possible to run the workshops, but
> at least the will is there )).
>
> I hope there's sufficient interest, and that we can proceed with organising
> the event!
>
>
> All the best,
>
> miksa
>
>
>
>
> --
> miska michael knapek - your local illusionist (designer)
> mob. +358-50-320-2616
> web: http://knapek.org
> http://twitter.com/miskaknapek
> animations: http://vimeo.com/miska
> images: http://flickr.com/miska_too/sets
> code/github: https://github.com/miskaknapek
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>



-- 
/emj

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


Re: [OSM-talk] Spoken street names

2016-08-16 Thread Hans De Kryger
*Regards,*

*Hans*

On Tue, Aug 16, 2016 at 10:13 PM, Rodrigo Rodríguez  wrote:

> Speakig of that, I have MAPS.ME installed on my Android and it's supposed
> the app has a voice navigation system but it doesn't work. Any thoughts on
> that?
>
> Regards,
>

​It just tells you where to turn, sadly it doesn't tell you the name of the
street. Hopefully they add that soon.​


>
> On 16/08/16 23:03, Hans De Kryger wrote:
>
> OsmAnd
> http://osmand.net/
>
>
> Scout
> http://www.telenav.com/products/scout/
>
> *Regards,*
> *Hans*
>
> On Tue, Aug 16, 2016 at 9:09 PM, Nick Hocking 
> wrote:
>
>> Is there any navigation software (for a Mobile phone) that uses offline
>> OSM data and also has spoken street names?
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
>
> --
> Rodrigo Rodríguezhttp://mundonomada.info
> __
> La rebeldíⒶ siempre sirve.
>
>
> ___
> 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] Spoken street names

2016-08-16 Thread Rodrigo Rodríguez
Speakig of that, I have MAPS.ME installed on my Android and it's
supposed the app has a voice navigation system but it doesn't work. Any
thoughts on that?

Regards,


On 16/08/16 23:03, Hans De Kryger wrote:
> OsmAnd
> http://osmand.net/
>
>
> Scout
> http://www.telenav.com/products/scout/
>
> *Regards,**
> *
> *Hans*
>
> On Tue, Aug 16, 2016 at 9:09 PM, Nick Hocking  > wrote:
>
> Is there any navigation software (for a Mobile phone) that uses
> offline OSM data and also has spoken street names?
>
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
> 
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

-- 
Rodrigo Rodríguez
http://mundonomada.info
__
La rebeldíⒶ siempre sirve.

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


Re: [OSM-talk] Spoken street names

2016-08-16 Thread Hans De Kryger
OsmAnd
http://osmand.net/


Scout
http://www.telenav.com/products/scout/

*Regards,*

*Hans*

On Tue, Aug 16, 2016 at 9:09 PM, Nick Hocking 
wrote:

> Is there any navigation software (for a Mobile phone) that uses offline
> OSM data and also has spoken street names?
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[talk-latam] Presentación OpenStreetView y Repositorio en Github

2016-08-16 Thread Gonzales, Miriam - (p)
Hola comunidad mapera,

Se agrega una herramienta más a la lista de posibilidades para la mejora de 
OpenStreetMap.

OpenStreetView fue presentada hace unas semanas en State of the Map US por 
Martijn Van Exel y Alexandre Illsei. La función principal es captura de 
imágenes a nivel calle que pueden ser consultadas en 
www.openstreetview.org

En los siguientes links podrán encontrar los detalles del funcionamiento, Wiki 
y repositorio de Github

http://www.openstreetmap.org/user/Mapanauta/diary/39282
https://github.com/openstreetview
http://wiki.openstreetmap.org/wiki/OpenStreetView

Saludos y gracias,

M

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


[OSM-talk] Spoken street names

2016-08-16 Thread Nick Hocking
Is there any navigation software (for a Mobile phone) that uses offline OSM
data and also has spoken street names?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Dave F


On 16/08/2016 17:28, Colin Smale wrote:


Dave, if the is_in values are based on common usage rather than 
administrative reality, then it would actually be correct to leave 
them unchanged.




If a better way of doing something is created then the old methods 
become redundant & should be removed for the reasons Andy Allan 
mentioned in a previous post in this thread. Sarah Hoffmann's reply in 
the Talk thread I posted clearly says is_in:* "is unnecessary"


The point I am trying to make, is that I see a need to support a 
variety of addressing/location systems, which are all correct in their 
own way, but useful for different things.




As far as I can see is_in:* is used for the same things as boundaries, 
but is less efficient & prone to errors.


Are you aware of any utilities that use is_in:*?

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


[OSM-talk] Fwd: Invitation: OSM Analytics Roadmap Chat

2016-08-16 Thread Cristiano Giovando
Hey fellow mappers,

Some of you already know and have been using OSM Analytics since its
launch in April [0], but for those who are not familiar with it,
here's the direct link http://osm-analytics.org

This was initially a small prototype project, but given the interest
and feedback by many in the OSM community, we're now thinking how to
scale it and include more functionalities.

To start the discussion around a roadmap, we are holding a public
community chat this Thursday, August 18th, at 17:00UTC [1] on Gitter:
https://gitter.im/hotosm/osm-analytics

Everyone is welcome to join - I think we will have some more technical
discussions on the infrastructure design, but also less technical ones
about feature requests and ideas for new functions.

All OSMA code is public here [2]. Would be great to also discuss how
to integrate other OSM applications that focus on statistics, quality
assurance, user analytics and validation into OSMA and vice-versa. One
example is this work [3] by Jennings Anderson, built on a similar
processing workflow/stack, that has lots of great insights and
visualizations on OSM contributors and data quality.

If you are around on Thursday, we'd love you to join and share your
ideas. See you then!

Cristiano


[0] 
https://hotosm.org/updates/2016-04-28_explore_how_the_world_is_mapped_with_osm_analytics

[1] 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+Analytics+Roadmap+Chat=20160818T17=1440=1

[2] https://github.com/hotosm/osm-analytics

[3] http://mapbox.github.io/osm-analysis-collab/osm-quality.html


-- 
Cristiano Giovando
Humanitarian OpenStreetMap Team
cristiano.giova...@hotosm.org
http://www.hotosm.org

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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Dave F


On 16/08/2016 21:35, Nicolás Alvarez wrote:

Wouldn't that lead to "mapping for the geocoder"? I'm sure that would
be frowned upon as much as "mapping for the renderer".


All tags are 'mapping for the renderer/geocoder/router. Otherwise you 
have just black lines, lots of 'You are here' signs stacked on top of 
each other & vehicles going round in circles.


Tagging *incorrectly* to suit the above is what's frowned upon.

Dave F.

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


Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Andy Townsend

On 16/08/2016 21:57, Colin Smale wrote:


Having just received another "too busy mapping" response to a 
changeset comment I have requested DWG to give alexkemp a 0-minute 
block to remind him of his duty to engage with the community in a 
proper way.




We (the Data Working Group) normally use 0-hour blocks as a "message 
that has to be read" for people who may have misconfigured email, to 
make sure that messages really are being seen by the mapper concerned.  
I normally end up writing a sentence along the lines of "... you'll be 
able to continue mapping immediately after reading this" just to make it 
clear that it's not a block as such (temporary or permanent).


I don't believe that a 0-hour block is appropriate in this case as 
there's no evidence that messages aren't being read (actions would 
suggest that they are).  Following up on previous messages to Alex I've 
added a discussion comment to 
http://www.openstreetmap.org/changeset/41481784 asking for the "out of 
office" messages not to be sent.


Obviously what we want to happen is to get everyone's engagement with 
how and why boundaries have been mapped as they are so far, and I've 
suggested that the talk-gb list is probably the best place for that 
(there's also the East Mids pub meetup in Derby next week, where a 
number of the protagonists will be present).  The more general point is 
(and this is a line that appears in many of the DWG messages that I 
send) that OSM is a collaborative project, and we need to work together 
to create the best map.  This doesn't mean that "the way that it is done 
now" is always right, but it does mean listening to other people, and a 
discussion putting across all points of view needs to be had.  It's 
worth pointing out that the discussion so far has certainly been useful 
to me, not least in learning that "is_in" is processed by Nominatim (to 
an extent at least - see 
https://lists.openstreetmap.org/pipermail/talk/2016-August/076596.html 
et al).


On a more general point one of the things that is often a surprise and a 
frustration to people and companies coming into OSM anew (especially 
companies) is that everything moves quite slowly - it's about creating a 
Canaletto rather than Sid from down the road applying a couple of coats 
of Dulux.  I suspect that that the speed perception might be a factor 
here too.


Best Regards,

Andy Townsend (SomeoneElse)




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


Re: [Talk-cz] Zpracování vrstevnic pro mapy

2016-08-16 Thread Lukáš Karas
Díky! To je přesně to co jsem hledal. Sice jsem musel investovat trochu 
manuální práce, ale moje mapy Alp už vypadají dokonale! :) 

Lukáš

Dne úterý 16. srpna 2016 16:16:45 CEST Jakub Sýkora napsal(a):
> V tom případě je tu pro tebe:
> 
> http://viewfinderpanoramas.org
> 
> K
> 
> Dne 16.8.2016 v 13:18 Lukáš Karas napsal(a):
> > Děkuji za shrnutí. Můj problém spočívá právě v tom dávkovém zpracování.
> > SRTMv4 vyžaduje pro stažení ověření účtem, což jsem ještě schopen do
> > Srtm2Osm dopsat. Ale pokud i SRTMv4 obsahuje "černá místa" v nějaké větší
> > míře, bylo by vhodné provést nějakou interpolaci...
> > 
> > A s tím už se mi dělat nechce a raději bych sáhnul po hotovém řešení ;-)
> > Ale o žádném nevím. Zároveň vidím webové mapy které mají ṕerfektní
> > vrtevnice...
> > 
> > Lukáš
> > 
> > Dne úterý 16. srpna 2016 10:05:25 CEST Jakub Sykora napsal(a):
> >> Ahoj,
> >> 
> >> záleží, odkud čerpáš SRTM data a zda jsou tam interpolované voidy. V
> >> surových datech toho dost chybí.
> >> Také je dobré se do těch zdrojových dat podívat, jak to vypadá v těch
> >> oblastech, kde selhal převod na vrstevnice, vypadá.
> >> 
> >> Jedna z možností je SRTM v4 ze http://srtm.csi.cgiar.org/
> >> Udělali tam hodně práce na kvalitě dat. Ale jsou to pouze 90m data (3
> >> vteřinová)
> >> 
> >> Pokud to chceš méně hranaté, můžeš zkusit jednovteřinová data, ale opět
> >> platí, že je potřeba v datech vyplnit voidy nějak rozumně, protože i tam
> >> nějaké jsou. Viz https://lta.cr.usgs.gov/SRTMVF a SRTM 1 Arc-Second
> >> Global a stahova tmožno přes http://earthexplorer.usgs.gov/
> >> 
> >> K
> >> 
> >> Dne 16.8.2016 v 09:37 Lukáš Karas napsal(a):
> >>> Ahoj, měl bych dotaz na lidi kolem projektu openstreetmap.cz:
> >>> Vrstevnice které jsou součástí map si zpracováváte sami, nebo stahujete
> >>> předpřipravené z nějaké služby?
> >>> 
> >>> Zkoušel jsem do svých mobilních map (postavených nad OSM Scout
> >>> knihovnou)
> >>> přidat vrstevnice, použil jsem Srtm2Osm tool pro vytvoření vrstevnic z
> >>> SRTMv2 dat od Nasa. Vše vypadalo vpořádku, dokud jsem nezkusil Alpy, kde
> >>> jsem narazil na tyto podivnosti:
> >>> http://www.karry.cz/files/ContourLines_bug.png
> >>> 
> >>> Na OSM wiki jsem se dočetl že SRTM data mají tento problém na místech
> >>> kde
> >>> byl sníh :-( Chtěl jsem vyzkoušet použít novější data (SRTMv3), ale pro
> >>> ten jsem zatím nenašel funkční nástroj...
> >>> 
> >>> Když se podívám na openstreetmap.cz, třeba na vrstvu zimní sporty tak
> >>> tento
> >>> problém se ve vrstevnicích nevyskytuje...
> >>> 
> >>> Poradíte prosím jaký zdroj a nástroje použít pro dokonalé vrstevnice?
> >>> 
> >>> Díky, Lukáš
> >>> 
> >>> 
> >>> 
> >>> ___
> >>> Talk-cz mailing list
> >>> Talk-cz@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-cz
> >> 
> >> ___
> >> Talk-cz mailing list
> >> Talk-cz@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-cz

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-ca] Mapping exit numbers and destinations in Canada

2016-08-16 Thread Paul Norman

On 8/11/2016 5:53 AM, Kevin Farrugia wrote:
Yes - recently bootprint, andrewpmk, and I have been changing and 
correcting the name tags to destination in Ontario along the 
400-Series highways. If you see a ramp/link that is named, it's fine 
to change it over to destination or correct a problem you find with it.


Destination tags are based on what the signs say. The name tags tend to 
come from CanVec and are sometimes unrelated to signage, so make sure 
you check the signs before adding a destination tag.


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


Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Colin Smale
Having just received another "too busy mapping" response to a changeset
comment I have requested DWG to give alexkemp a 0-minute block to remind
him of his duty to engage with the community in a proper way. 

Colin

On 2016-08-16 14:55, Dave F wrote:

> +1
> 
> Also his use of is_in:* is also redundant when the boundary tag is used,
> 
> Dave F.
> 
> On 16/08/2016 13:25, Andy Allan wrote: On 16 August 2016 at 13:11, Will 
> Phillips  wrote:
> 
> Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
> consistent with other uses of the ref tag in OSM. Also, I agree that tagging
> area values seems redundant, but perhaps doesn't do any harm in this case. I
> do think at least, they should be retagged, perhaps to area:ha or
> area:hectares? No, they should be removed.
> 
> While it seems like tags like this do little harm, they encourage
> future importers to follow the same path, and our database ends up
> full of cruft. It's also off-putting to mappers, who might be scared
> off from fixing the geometry of features since they don't know how to
> recalculate the area.
> 
> There's no good reason to keep them.
> 
> Thanks,
> Andy
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Andreas Schmidt


Am 16.08.2016 um 13:59 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> Il giorno 16 ago 2016, alle ore 12:52, Richard  ha 
>> scritto:
>>
>> Übrigens... wer hat hier sein vollstes Vertrauen in ein "Deutsche Telekom 
>> Root CA"?
>
> +1, Amerikaner bezieht sich auch auf deren Alliierte und sonstwie Hörige (die 
> "westliche Welt"), und wer da Bedenken hat, der kann ja in Russland oder 
> China oder  sein Zertifikat ausstellen lassen :) Eigentlich gibt es keine 
> vertrauenswürdigen Zertifikate außer denen, die man sich selbst generiert
Doch, Honest Achmed ist auch vertrauenswürdig. Leider sah Mozilla das
anders. (
http://www.heise.de/security/meldung/Der-ehrliche-Achmed-bittet-um-Vertrauen-1231083.html
)

scnr
Andreas




signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Sarah Hoffmann
On Tue, Aug 16, 2016 at 09:50:05PM +0200, Hakuch wrote:
> Hey Sarah, do you have documentations that explain how nominatim
> processes the queries? That could be an answer to questions like that one

Not really. You can have a look at the presentation I gave at SOTM
Birmingham[1] but it's a bit dated and not really something where you
'look up' these things.

Sarah

[1] http://osm.lonvia.de/presentations/2013-nominatim.html

> 
> On 16.08.2016 21:27, Sarah Hoffmann wrote:
> > On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> >> Hi
> >>
> >> I've heard a claim from a user who still wants to use the is_in:*
> >> tag as well as boundary tags that Nominatim uses is_in as preference
> >> because "geospacial mathematics is resource intensive".
> >>
> >> Is this true?
> > 
> > Not at all. Nominatim happily processes boundaries and always prefers
> > it over any other hierarchy information.
> > 
> > It is true that it still understands is_in:* tags but prbably not in
> > the way you would think. First of all, they are completely ignored
> > on anything at building level (e.g address points and POIs). For
> > everything else Nominatim always uses a geospatial match when
> > computing the address. is_in:* is just good to help make a decision
> > when there are two equally well suited candidates, generally when, say,
> > a road is right between two city place nodes. As soon as there are
> > boundaries, multiple candidates don't happen anymore, so that is_in:*
> > is ignored for all practical purposes.
> > 
> >> I thought geospacial calculations were fairly light on processing power.
> >>
> >> I also thought is_in:* was to be discouraged. Being hard coding, if
> >> a boundary was to change all affected entities would become
> >> inaccurate.
> > 
> > Yes, if possible always draw boundaries. They are more precise and easier
> > to maintain. is_in is unnecessary.
> > 
> > Kind regards
> > 
> > Sarah
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> > 

> pub  4096R/3CBE432B 2015-09-17 Hakuch 
> sub  4096R/77F3A4C3 2015-09-17 [expires: 2016-09-16]

> ___
> 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] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Nicolás Alvarez
Wouldn't that lead to "mapping for the geocoder"? I'm sure that would
be frowned upon as much as "mapping for the renderer".

-- 
Nicolás

2016-08-16 16:50 GMT-03:00 Hakuch :
> Hey Sarah, do you have documentations that explain how nominatim
> processes the queries? That could be an answer to questions like that one
>
> On 16.08.2016 21:27, Sarah Hoffmann wrote:
>> On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
>>> Hi
>>>
>>> I've heard a claim from a user who still wants to use the is_in:*
>>> tag as well as boundary tags that Nominatim uses is_in as preference
>>> because "geospacial mathematics is resource intensive".
>>>
>>> Is this true?
>>
>> Not at all. Nominatim happily processes boundaries and always prefers
>> it over any other hierarchy information.
>>
>> It is true that it still understands is_in:* tags but prbably not in
>> the way you would think. First of all, they are completely ignored
>> on anything at building level (e.g address points and POIs). For
>> everything else Nominatim always uses a geospatial match when
>> computing the address. is_in:* is just good to help make a decision
>> when there are two equally well suited candidates, generally when, say,
>> a road is right between two city place nodes. As soon as there are
>> boundaries, multiple candidates don't happen anymore, so that is_in:*
>> is ignored for all practical purposes.
>>
>>> I thought geospacial calculations were fairly light on processing power.
>>>
>>> I also thought is_in:* was to be discouraged. Being hard coding, if
>>> a boundary was to change all affected entities would become
>>> inaccurate.
>>
>> Yes, if possible always draw boundaries. They are more precise and easier
>> to maintain. is_in is unnecessary.
>>
>> Kind regards
>>
>> Sarah

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


Re: [Talk-GB] Possible use of OS triangulation stations to determine aerial imagery offset

2016-08-16 Thread David Woolley

On 16/08/16 15:22, Greg wrote:

There is also a FOI request with a full CSV file here:


FOI responses don't remove any copyright and I don't think they even 
given any right to republish the data.


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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Hakuch
Hey Sarah, do you have documentations that explain how nominatim
processes the queries? That could be an answer to questions like that one

On 16.08.2016 21:27, Sarah Hoffmann wrote:
> On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
>> Hi
>>
>> I've heard a claim from a user who still wants to use the is_in:*
>> tag as well as boundary tags that Nominatim uses is_in as preference
>> because "geospacial mathematics is resource intensive".
>>
>> Is this true?
> 
> Not at all. Nominatim happily processes boundaries and always prefers
> it over any other hierarchy information.
> 
> It is true that it still understands is_in:* tags but prbably not in
> the way you would think. First of all, they are completely ignored
> on anything at building level (e.g address points and POIs). For
> everything else Nominatim always uses a geospatial match when
> computing the address. is_in:* is just good to help make a decision
> when there are two equally well suited candidates, generally when, say,
> a road is right between two city place nodes. As soon as there are
> boundaries, multiple candidates don't happen anymore, so that is_in:*
> is ignored for all practical purposes.
> 
>> I thought geospacial calculations were fairly light on processing power.
>>
>> I also thought is_in:* was to be discouraged. Being hard coding, if
>> a boundary was to change all affected entities would become
>> inaccurate.
> 
> Yes, if possible always draw boundaries. They are more precise and easier
> to maintain. is_in is unnecessary.
> 
> Kind regards
> 
> Sarah
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Sarah Hoffmann
On Tue, Aug 16, 2016 at 02:29:26PM +0100, Dave F wrote:
> Hi
> 
> I've heard a claim from a user who still wants to use the is_in:*
> tag as well as boundary tags that Nominatim uses is_in as preference
> because "geospacial mathematics is resource intensive".
> 
> Is this true?

Not at all. Nominatim happily processes boundaries and always prefers
it over any other hierarchy information.

It is true that it still understands is_in:* tags but prbably not in
the way you would think. First of all, they are completely ignored
on anything at building level (e.g address points and POIs). For
everything else Nominatim always uses a geospatial match when
computing the address. is_in:* is just good to help make a decision
when there are two equally well suited candidates, generally when, say,
a road is right between two city place nodes. As soon as there are
boundaries, multiple candidates don't happen anymore, so that is_in:*
is ignored for all practical purposes.

> I thought geospacial calculations were fairly light on processing power.
> 
> I also thought is_in:* was to be discouraged. Being hard coding, if
> a boundary was to change all affected entities would become
> inaccurate.

Yes, if possible always draw boundaries. They are more precise and easier
to maintain. is_in is unnecessary.

Kind regards

Sarah

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


Re: [Talk-cz] kvartální piva

2016-08-16 Thread Milan Cerny
Ještě jsem nikoho ze spolutvůrců OSM osobně neviděl, tak kdyby bylo pivo v 
Praze nebo okolí, rád se také na jedno či více zastavím.
Alespoň se dozvím něco nového od OSM mazáků :-)
Pondělí - čtvrtek večer kdykoliv.

Milan 
 

__
> Od: Petr Vozdecký 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 16.08.2016 15:22
> Předmět: Re: [Talk-cz] kvartální piva
>
>...sem rikal, pivo je argument... kdyz bych to nazval "Kvartalni limonada", 
>tak nikdo nedorazi... :o)
>
>vop
>
>
>-- Původní zpráva --
>Od: honny 
>Komu: OpenStreetMap Czech Republic 
>Datum: 16. 8. 2016 13:01:32
>Předmět: Re: [Talk-cz] kvartální piva
>
>"Zdar,
>
>Dne 16. srpna 2016 11:25 Petr Vozdecký  napsal(a):
>> ...no já už jsem si to do svého kalendáře dal.
>
>taky tak. :)
>Co se tyka Brna a terminu v pracovnim tydnu, nemam s tim problem a prijdu 
>rad.
>
>
>
>h.
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz"=
>
>--
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>
>

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


Re: [Talk-it] Registratore audio per android

2016-08-16 Thread Cascafico Giovanni
Qualche mese fa Tempestini aveva segnalato ifttt e la sua app "do" che
permette di programmare un pulsante sul.desktop android. La usavano per
mappare velocemente tombini o un qualunque cosa facendogli scriverre una
riga su un foglio elettronico nel cloud.

--
cascafico.altervista.org
twitter.com/cascafico
Il 16/ago/2016 19:07 "Germano Massullo"  ha
scritto:

> Il 16 agosto 2016 17:45, Michele iw1gfv  ha scritto:
> > Ciao a tutti!
> > Ho risolto il problema, evviva!
> > L'app usata si chiama automate.
> > Permette di eseguire una lista di operazioni.
> > Ho creato una lista con 2 operazioni:
> > Registrazione per 3 secondi
> > Beep che avvisa la fine della registrazione.
> >
> > Con headset button controller lancio la scorciatoia, e sento il beep del
> > lancio, registro la voce e sento il beep di fine, con un solo click sul
> > pulsante del casco da bici.
>
> Mmh e come fai per la georeferenziazione?
>
> ___
> 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: [Talk-es] Academias de clases particulares

2016-08-16 Thread Johnattan Rupire
+1
buena idea Santiago.
Saludos

El 26/07/16 a las 15:55, Santiago Crespo escribió:
> Creo que además podemos añadir algunas de las etiquetas usadas en
> amenity=school[1]:
> 
>  * operator=*
>  * capacity=*
>  * isced:level=* [2]
>  * min_age=* y max_age=*

-- 
Johnattan Rupire
@johnarupire


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


Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Colin Smale
Dave, if the is_in values are based on common usage rather than
administrative reality, then it would actually be correct to leave them
unchanged. 

The point I am trying to make, is that I see a need to support a variety
of addressing/location systems, which are all correct in their own way,
but useful for different things. In order to do that we need additional
tagging systems, otherwise people will try to force-fit (for example)
postal addresses (postcode sectors, post towns etc) onto administrative
boundaries and the result will be neither fish nor fowl. 

Is Rochester in Kent? Most people would say yes. "Where am I?" (powered
by Nominatim) returns:

* 

Troy Town, Rochester, Medway, South East, England, United Kingdom [1] 

Which while administratively correct (except for Troy Town which is a
suburb, modelled in OSM as a simple node without a defined boundary), is
not particularly useful (IMHO of course) - a more typical human would
expect "Rochester, Kent, England, United Kingdom" 

I am glad you asked about Nominatim's algorithm. I suspect there is an
element of black magic involved. I hope they do not keep it too secret
in order not to encourage "tagging for the renderer" but some insights
would definitely be useful. Then we want to think what we actually
expect Nominatim to return for reverse geocoding. Postal address?
Administrative divisions? Local perception? 

Colin 

On 2016-08-16 17:37, Dave F wrote:

> I queried Alex's rational:
> 
> http://www.openstreetmap.org/user/alexkemp/diary/39062
> 
> As I noted is_in tags are hard-coded so become inaccurate if boundaries 
> change.
> 
> I also asked about Nominatim's search criteria on the Talk forum:
> 
> https://lists.openstreetmap.org/pipermail/talk/2016-August/076592.html
> 
> Dave F.
> 
> On 16/08/2016 16:01, Colin Smale wrote: 
> 
> In the specific case of the UK, I am not convinced that is_in has no value at 
> all. This is because of the huge divergence between people's perceptions and 
> administrative reality. If you ask someone to give their location/current 
> address, they will most likely refer to the postal addressing system, which 
> is completely unconnected to administrative boundaries. They will also tend 
> to add a level of detail to the address which the postal system does not 
> require, but tolerates. The admin boundaries represent the legal status, but 
> it will be more relevant to most people's minds if Nominatim et al. recognise 
> an alternative place hierarchy. I think place=* polygons/nodes may already be 
> used, but the results sometimes seem to be an awful jumble of admin 
> boundaries and place-based info. The fact that large swathes of the 
> countryside are unparished (i.e. no admin_level=10 polygon with a name) makes 
> the quality/accuracy of the results variable according to the location. Alex 
> Kemp is
experimenting with introducing artificial admin_level=10 polygons for these 
unparished areas with names based on historical data to help Nominatim which 
IMHO is not the way to do it. Parishes are useless for navigation/addressing 
anyway. 
> 
> Bottom line is that locations have multiple ways of being defined, and this 
> is not currently embraced by OSM which wants a nice simple address+polygon 
> hierarchy. For many countries that works, but not for the UK. It is possible 
> that the is_in data can give an alternative perspective. BUT it needs to be 
> kept distinct from the admin boundaries, which are a matter of law, and it 
> needs to give complete coverage of the country, which at present is probably 
> not the case. 
> 
> Colin
> 
> On 2016-08-16 14:55, Dave F wrote: 
> +1
> 
> Also his use of is_in:* is also redundant when the boundary tag is used,
> 
> Dave F.
> 
> On 16/08/2016 13:25, Andy Allan wrote: On 16 August 2016 at 13:11, Will 
> Phillips  wrote:
> 
> Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
> consistent with other uses of the ref tag in OSM. Also, I agree that tagging
> area values seems redundant, but perhaps doesn't do any harm in this case. I
> do think at least, they should be retagged, perhaps to area:ha or
> area:hectares? No, they should be removed.
> 
> While it seems like tags like this do little harm, they encourage
> future importers to follow the same path, and our database ends up
> full of cruft. It's also off-putting to mappers, who might be scared
> off from fixing the geometry of features since they don't know how to
> recalculate the area.
> 
> There's no good reason to keep them.
> 
> Thanks,
> Andy
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

___
Talk-GB mailing list
Talk-GB@openstreetmap.org

Re: [Talk-it] Registratore audio per android

2016-08-16 Thread Germano Massullo
Il 16 agosto 2016 17:45, Michele iw1gfv  ha scritto:
> Ciao a tutti!
> Ho risolto il problema, evviva!
> L'app usata si chiama automate.
> Permette di eseguire una lista di operazioni.
> Ho creato una lista con 2 operazioni:
> Registrazione per 3 secondi
> Beep che avvisa la fine della registrazione.
>
> Con headset button controller lancio la scorciatoia, e sento il beep del
> lancio, registro la voce e sento il beep di fine, con un solo click sul
> pulsante del casco da bici.

Mmh e come fai per la georeferenziazione?

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


Re: [Talk-it] Registratore audio per android

2016-08-16 Thread Michele iw1gfv
Ciao a tutti!
Ho risolto il problema, evviva!
L'app usata si chiama automate.
Permette di eseguire una lista di operazioni.
Ho creato una lista con 2 operazioni:
Registrazione per 3 secondi
Beep che avvisa la fine della registrazione.

Con headset button controller lancio la scorciatoia, e sento il beep del 
lancio, registro la voce e sento il beep di fine, con un solo click sul 
pulsante del casco da bici.


-- 
iw1gfv.it
piemontegps.altervista.org
badgersclub.org___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Dave F

I queried Alex's rational:

http://www.openstreetmap.org/user/alexkemp/diary/39062

As I noted is_in tags are hard-coded so become inaccurate if boundaries 
change.


I also asked about Nominatim's search criteria on the Talk forum:

https://lists.openstreetmap.org/pipermail/talk/2016-August/076592.html

Dave F.


On 16/08/2016 16:01, Colin Smale wrote:


In the specific case of the UK, I am not convinced that is_in has no 
value at all. This is because of the huge divergence between people's 
perceptions and administrative reality. If you ask someone to give 
their location/current address, they will most likely refer to the 
postal addressing system, which is completely unconnected to 
administrative boundaries. They will also tend to add a level of 
detail to the address which the postal system does not require, but 
tolerates. The admin boundaries represent the legal status, but it 
will be more relevant to most people's minds if Nominatim et al. 
recognise an alternative place hierarchy. I think place=* 
polygons/nodes may already be used, but the results sometimes seem to 
be an awful jumble of admin boundaries and place-based info. The fact 
that large swathes of the countryside are unparished (i.e. no 
admin_level=10 polygon with a name) makes the quality/accuracy of the 
results variable according to the location. Alex Kemp is experimenting 
with introducing artificial admin_level=10 polygons for these 
unparished areas with names based on historical data to help Nominatim 
which IMHO is not the way to do it. Parishes are useless for 
navigation/addressing anyway.


Bottom line is that locations have multiple ways of being defined, and 
this is not currently embraced by OSM which wants a nice simple 
address+polygon hierarchy. For many countries that works, but not for 
the UK. It is possible that the is_in data can give an alternative 
perspective. BUT it needs to be kept distinct from the admin 
boundaries, which are a matter of law, and it needs to give complete 
coverage of the country, which at present is probably not the case.


Colin

On 2016-08-16 14:55, Dave F wrote:


+1

Also his use of is_in:* is also redundant when the boundary tag is used,

Dave F.

On 16/08/2016 13:25, Andy Allan wrote:
On 16 August 2016 at 13:11, Will Phillips > wrote:



Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
consistent with other uses of the ref tag in OSM. Also, I agree that tagging
area values seems redundant, but perhaps doesn't do any harm in this case. I
do think at least, they should be retagged, perhaps to area:ha or
area:hectares?

No, they should be removed.

While it seems like tags like this do little harm, they encourage
future importers to follow the same path, and our database ends up
full of cruft. It's also off-putting to mappers, who might be scared
off from fixing the geometry of features since they don't know how to
recalculate the area.

There's no good reason to keep them.

Thanks,
Andy

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



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



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


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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Andy Townsend

On 16/08/2016 16:19, Hakuch wrote:

following the wiki, its not deprecated

https://wiki.openstreetmap.org/wiki/Key:is_in


I was surprised when I read that the other day too...


However, I really would love to see a scheme that shows how nominatim
finds it results..


There's the nominatim.openstreetmap.org site (but that might not be want 
you want).


http://nominatim.openstreetmap.org/details.php?place_id=660625

Doesn't explicitly mention "is_in", but I guess you could try it 
somewhere there are enclaves and exclaves and see what it returns.


Best Regards,

Andy


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


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-16 Thread Fayor Uno
Perché parli ancora di governo centrale e vari pezzi? non so quante volte ho 
scritto che lo Stato in materia di enti locali ha ormai competenze 
ridottissime, specialmente nelle regioni a statuto speciale.

I nomi delle località (i place) sono decisi dai singoli comuni.

I nomi dei comuni sono decisi dalle regioni (e anche delle province in quelle a 
statuto speciale).

Solo i nomi delle province (nelle regioni a statuto ordinario) sono (ancora) 
decisi dallo Stato.

I nomi delle regioni sono nella Costituzione.



Da: Martin Koppenhoefer 
Inviato: martedì 16 agosto 2016 11.10
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] [english 100%] Re: Edit war Sardegna



sent from a phone

> Il giorno 16 ago 2016, alle ore 09:06, Vittorio Bertola  ha 
> scritto:
>
> L'unica soluzione che non crea arbitrarietà, flame infiniti e accuse di 
> parzialità (o peggio dà potenzialmente spazio ad accuse politicizzate di 
> leghismo/separatismo/razzismo...) è quella di usare anche per i place i soli 
> nomi ufficiali, in italiano e basta


allora è messo davvero male l'Italia, se si vuole la forza della legge e del 
governo centrale per tenere insieme tutti i vari pezzi? Se fosse davvero così 
sarebbe solo questione del tempo finché volerebbe tutto a parte, non si riesce 
tenere insieme perenne con la forza cosa vuole separarsi ;-)


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

Pagina di informazioni della lista 
Talk-it
lists.openstreetmap.org
Lista dedicata agli utenti di lingua italiana di OpenStreetMap. Un luogo dove 
discutere progetti, eventi e altro. Per consultare la raccolta dei messaggi ...



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


Re: [OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Hakuch
following the wiki, its not deprecated

https://wiki.openstreetmap.org/wiki/Key:is_in

However, I really would love to see a scheme that shows how nominatim
finds it results..

On 16.08.2016 15:29, Dave F wrote:
> Hi
> 
> I've heard a claim from a user who still wants to use the is_in:* tag as
> well as boundary tags that Nominatim uses is_in as preference because
> "geospacial mathematics is resource intensive".
> 
> Is this true?
> 
> I thought geospacial calculations were fairly light on processing power.
> 
> I also thought is_in:* was to be discouraged. Being hard coding, if a
> boundary was to change all affected entities would become inaccurate.
> 
> Thanks
> Dave F.
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



0x3CBE432B.asc
Description: application/pgp-keys


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


Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Colin Smale
In the specific case of the UK, I am not convinced that is_in has no
value at all. This is because of the huge divergence between people's
perceptions and administrative reality. If you ask someone to give their
location/current address, they will most likely refer to the postal
addressing system, which is completely unconnected to administrative
boundaries. They will also tend to add a level of detail to the address
which the postal system does not require, but tolerates. The admin
boundaries represent the legal status, but it will be more relevant to
most people's minds if Nominatim et al. recognise an alternative place
hierarchy. I think place=* polygons/nodes may already be used, but the
results sometimes seem to be an awful jumble of admin boundaries and
place-based info. The fact that large swathes of the countryside are
unparished (i.e. no admin_level=10 polygon with a name) makes the
quality/accuracy of the results variable according to the location. Alex
Kemp is experimenting with introducing artificial admin_level=10
polygons for these unparished areas with names based on historical data
to help Nominatim which IMHO is not the way to do it. Parishes are
useless for navigation/addressing anyway. 

Bottom line is that locations have multiple ways of being defined, and
this is not currently embraced by OSM which wants a nice simple
address+polygon hierarchy. For many countries that works, but not for
the UK. It is possible that the is_in data can give an alternative
perspective. BUT it needs to be kept distinct from the admin boundaries,
which are a matter of law, and it needs to give complete coverage of the
country, which at present is probably not the case. 

Colin

On 2016-08-16 14:55, Dave F wrote:

> +1
> 
> Also his use of is_in:* is also redundant when the boundary tag is used,
> 
> Dave F.
> 
> On 16/08/2016 13:25, Andy Allan wrote: On 16 August 2016 at 13:11, Will 
> Phillips  wrote:
> 
> Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
> consistent with other uses of the ref tag in OSM. Also, I agree that tagging
> area values seems redundant, but perhaps doesn't do any harm in this case. I
> do think at least, they should be retagged, perhaps to area:ha or
> area:hectares? No, they should be removed.
> 
> While it seems like tags like this do little harm, they encourage
> future importers to follow the same path, and our database ends up
> full of cruft. It's also off-putting to mappers, who might be scared
> off from fixing the geometry of features since they don't know how to
> recalculate the area.
> 
> There's no good reason to keep them.
> 
> Thanks,
> Andy
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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


Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Microgamer
As Hakuch already says: The project "new server" will take some time.
I don't know what all has to be done, to fire up the server, set the admins 
into position etc.
I think that we should go with an other forum, because fluxbb seems not to be 
that easy to handle.
Then all software we need has to be installed on the server. Then the forum 
itself comes onto the server.
This is the time when we have to have a template which matches the OSM style. 
Several plugins have to been written/installed. E.g. the OAuth-Plugin.

In general for the server i would expect that we have 3 admins and a 3rd 
organisation (OSMF) with credentials for the server, the database and the 
forum-administration. So this case cannot happen. More rights for the mods are 
possible as well :DD

So it's a bit of work and i think we should start as fast as possible with this 
project.
With the freeze-time sb has already said, Iceland has to wait at least 4 weeks 
for their forum to be installed. So we don't have that much time.
I assume that some organisation, probably the OSMF, has to put the admins into 
power. So sb, whe knows the system better than me, should probably write the 
procedure here.

An other thing I don't understand... Why do we have to wait, when the current 
admin didn't answer the question from iceland for some month already?

RegardsMicro


Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.


 Original Message 
Subject: Re: [OSM-talk] Forum admin(s) wanted
Local Time: 16. August 2016 12:40 PM
UTC Time: 16. August 2016 10:40
From: dan...@xn--ko-wla.pl
To: talk@openstreetmap.org

W dniu 16.08.2016 12:04, Hakuch napisał(a):

> as this new-server-software project will take some time. How do you
> think about hijacking another country-subforum? There are a lot where
> no
> one is active with only very few posts. I would accept it as temporary
> solution.

No need to invade Uruguay or Venezuela (both low volume with last
activity in March)... ;-P I think general chat is the best place to
start, since it is also low volume and may be used for things which have
no better place to be discussed - especially with subjects like
"[Iceland] National parks":

http://forum.openstreetmap.org/viewforum.php?id=9

If Lambertus ever wake up, it will be just a matter of pushing them to a
new subforum, so nothing would be lost and no fragmentation will occur.
If not, it will still be easy to do on a new server.

It would be a pity to not start community work just because there is no
optimal place!

--
"Low, low, low..." [M. Kempa]

___
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: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread jzvc

Dne 16.8.2016 v 15:33 Michal Poupa napsal(a):



BTW: Treba RLP Ruzyne se da chytat klidne i v okoli Brna ..


To že sedí v Praze - Jenči ještě neznamená že i vysílač je v Prsze -
Jenči.



Je to OT, ale rec je o Ruzyni, ne o Jenci => vez LKPR, ne aproach a 
spol. Samo je to dany frekvencema/modulaci. Treba ADS-B se da chytat na 
kus dratu (doslova) na 300km+


Ostatne, i ten mobilni telefon se umi spojit "na dohled", coz je klidne 
60km+ pokud vylezes na kopec. Tech 1-2W co to umi na vystupu je pomerne 
hodne slusnej vykon.




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




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


[Talk-GB] Possible use of OS triangulation stations to determine aerial imagery offset

2016-08-16 Thread Greg
Dear all,

Ordnance Survey has a database of triangulation stations and their
precise locations as OSGB36 (National Grid) co-ordinates publicly
available here:
https://www.ordnancesurvey.co.uk/gps/legacy-control-information/triangulation-stations.
There is also a FOI request with a full CSV file here:
https://www.ordnancesurvey.co.uk/about/governance/foi/questions/2015/0056.html.
I'm not sure under what licence the co-ordinates are published though.

It struck me that accurate co-ordinates for the visible stations such as
church spires, masts and water towers could be helpful in accurately
determining the offset of aerial imagery. It's possible to convert the
CSV to a GPX file with WGS84 lat/lon using QGIS (although I couldn't get
JOSM to display the metadata for each point). The imagery can then be
aligned to these points, bearing in mind of course that the imagery is
often taken from an angle (see
http://wiki.openstreetmap.org/wiki/Roof_modelling#Drawing_of_simple_building_outlines).

Best wishes,
Greg.

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


Re: [Talk-it] Info su livelli mappa

2016-08-16 Thread Alessandro

Il 16/08/2016 13:55, Pko . ha scritto:

Ciao a tutti,
Vorrei sapere se è possibile agire anche sulle informazioni contenute
dalla mappa ai vari livelli di ingrandimento. Ad esempio per migliorare
la consultazione della mappa perché non inserire i nomi delle vallate
alpine o quello delle regioni/dipartimenti, ecc.?
Oppure mettere in evidenza il nome dei passi alpini principali?

Grazie, saluti
Piccowit




Ciao,

dalle caratteristiche fisiche descritte stai pensando ad una mappa 
escursionistica che visualizza anche le curve di livello.
Al momento nelle visualizzazioni ospitate sul sito openstreetmap.org la 
cosa che si avvicina di più è la 'Mappa ciclabile' gestita da Andy Allan.
Da escursionista/alpinista/arrampicatore/ravanatore che sono la 'Mappa 
ciclabile' la considero decente ma è chiaramente un compromesso tra le 
esigenze dei ciclisti e quelle delle 4 categorie in cui mi ritrovo :-)
Se nella visualizzazione 'Standard' vedo almeno i passi e le elevazioni 
delle vette, nella 'ciclabile' non trovo queste caratteristiche ma vedo 
le curve di livello. In nessuna delle due vedo però i simboli dei 
sentieri che invece trovo come opzione in http://hikebikemap.org/ 
(selezionando 'Lonvia's Hiking Routes' dal menù).


Tutto questo per dire che se ti accontenti di vedere il nome delle 
vallate nella visualizzazione Standard allora puoi aprire un ticket al 
link indicato da Martin, se però (come il sottoscritto) vorresti avere 
una mappa utilizzabile prettamente in ambiente montano allora 
occorrerebbero molti più cambiamenti.


Alessandro Ale_Zena_IT


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


Re: [Talk-cz] 5x červená

2016-08-16 Thread Petr Holub
> Souhlasím, ona k tomu ještě neproběhla žádná zásadní diskuse, resp. spíše 
> obecný a tichý
> souhlas... Myslím, že v takovém případě asi nezbývá než fáze 2 - začít to 
> nasazovat a
> sledovat, zda se to projeví někde nějak negativně, zda se objeví nějaké 
> nedostatky apod. Viz
> zrovinka ten poznatek u těch whellchair s (na wiki) nedefinovanou položkou
> osmc:symbol=red:white:red_whellchair. Což nijak nevadí tomu navrženému 
> schematu, spíše to
> ukazuje, co ještě v návaznosti na praxi zlepšit.

Souhlas. Jen je potreba, abys tu fazi vyhlasil - kdy zacne a jestli se maji
zrovna nejak hromadne upravit stavajici relace.

A bylo by dobre pri tom jeste rozetnout, jak se bude pouzivat tag network.
Puvodni na OTM by bylo nejak navrzene, pak jsme o tom debatovali v listu,
ale ze by z toho byl nejaky definitivni zaver, to jsem moc nepostrehl.

Mozna jeste po formalni strance: v OSM existuje mechanismus hlasovani
pro akceptovani/zamitnuti ruznych navrhu. Nemeli bychom ho zacit taktez
pouzivat? Mozna by to bylo efektivnejsi na dokoncovani veci a jejich prevod
do provozniho stavu, nez pomerne nestrukturovana diskuse v mailing listu.

Petr


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


[OSM-talk] Nominatim - Does it use the is_in tag?

2016-08-16 Thread Dave F

Hi

I've heard a claim from a user who still wants to use the is_in:* tag as 
well as boundary tags that Nominatim uses is_in as preference because 
"geospacial mathematics is resource intensive".


Is this true?

I thought geospacial calculations were fairly light on processing power.

I also thought is_in:* was to be discouraged. Being hard coding, if a 
boundary was to change all affected entities would become inaccurate.


Thanks
Dave F.

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


Re: [Talk-cz] 5x červená

2016-08-16 Thread Petr Vozdecký


-- Původní zpráva --
Od: Petr Holub 
Komu: 'OpenStreetMap Czech Republic' 
Datum: 16. 8. 2016 13:32:16
Předmět: Re: [Talk-cz] 5x červená

"> Coz mne jeste pripomina jednu vec: budme opatrni s temi navrhy na zmeny
> znaceni. Pri dovolenkovem mapovani v okoli Kremesniku (Pelhrimova) jsem
> narazil na to, ze uz nektere trasy postradaji tag kct_*, coz muze v 
soucasnem
> stavu cinit renderum potize (napr. pro nasi mtbmap.cz - byt tam jeste 
cekam
> na overeni, protoze Martin ted resi problem s nastroji v ramci updatu 
dat).
> Takze pokud mame navrh na nove znaceni zalozene pouze na osmc:symbol, melo
> by byt jasne, ze je to "jen" navrh a taky by melo byt jasne receno, kdy se
> tento navrh preklopi do produkcniho stavu, aby se tedy daly zacit 
upravovat
> renderery.
> 
> Petr
> 
> 
> 
> 
> Toto je Petře IMHO dávno překonaný problém. Renderery se dávno na tag kct_
barva=* nespoléhají,
> resp. jej ignorují. Konkrétně MTBmap též.

Uz mi to Martin taky psal - takze by bylo dobre to jeste pro jistotu
overit na nejake takove trase. Ted jede novy update dat a snad by to do
konce tydne melo dobehnout, takze pak bude prilezitost to zkontrolovat.

Ale v kazdem pripade plati, ze bychom meli rict, kdy se ten navrh preklopi
do provozniho (akceptovaneho) stavu, kterym se maji vsichni ridit. Protoze
zatim je to jen navrh a vsichni by jeste meli pouzivat to stare znaceni. 

Petr"
 




Souhlasím, ona k tomu ještě neproběhla žádná zásadní diskuse, resp. spíše 
obecný a tichý souhlas... Myslím, že v takovém případě asi nezbývá než fáze 
2 - začít to nasazovat a sledovat, zda se to projeví někde nějak negativně, 
zda se objeví nějaké nedostatky apod. Viz zrovinka ten poznatek u těch 
whellchair s (na wiki) nedefinovanou položkou osmc:symbol=red:white:red_
whellchair. Což nijak nevadí tomu navrženému schematu, spíše to ukazuje, co 
ještě v návaznosti na praxi zlepšit.




vop

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


Re: [Talk-cz] kvartální piva

2016-08-16 Thread Petr Vozdecký
...sem rikal, pivo je argument... kdyz bych to nazval "Kvartalni limonada", 
tak nikdo nedorazi... :o)

vop


-- Původní zpráva --
Od: honny 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 8. 2016 13:01:32
Předmět: Re: [Talk-cz] kvartální piva

"Zdar,

Dne 16. srpna 2016 11:25 Petr Vozdecký  napsal(a):
> ...no já už jsem si to do svého kalendáře dal.

taky tak. :)
Co se tyka Brna a terminu v pracovnim tydnu, nemam s tim problem a prijdu 
rad.



h.

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


Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread Petr Vozdecký
-- Původní zpráva --
Od: jzvc 
"
Cus, v OSM stejne nemas data ani na to, abys udelal nejakej hypotetickej 
vypocet. Nemas informace o terenu, nemas informace o prekazkach, i pokud 
budes mit vysku budov, tak mas relativni, ale ne absolutni ..."
No to prave naopak teoreticky mas, byt v kvalite OSM, tedy vrstevnice (SRTM)
a vysky budov (jsou-li zadany), cili s teoretickou znalosti rady dalsich 
technickych hodnot ke konkretni BTS (a s jistotou, ze jsou uplne a aktualni)
se da teoreticka mapa malovat. Ale jak jsem jiz uvedl, jeji vypovidajici 
hodnota je nulova - vysledkem je vzdy jen informativni hodnota "tady by mel 
byt dle vypoctu signal na danem kmitoctu daneho typu modulace o sile -xy 
dBm". A kdyz neni, tak jen pokrcis rameny a reknes: "neni". A neni ti to 
divny. Zatim co od kartografickeho dila (= mapy) ocekavas informaci "tady JE
cesta", "tady JE objekt" atd. a ne "tady BY MELO dle vypoctu cosi byt"


 
"
BTW: Treba RLP Ruzyne se da chytat klidne i v okoli Brna ..."
to je jina pisnicka - to je dany AM modulaci a z jejiho principu moznym 
pouzitim vice vysilacu... nicmene bych se (aniz bych do podrobna studoval 
puvodni material, ze ktereho tento diskus vznikl) v ramci OSM (nebo alespon 
OSMcz) do "mapovani pokryti signalem" (ci jinymi sluzbami) vubec nepoustel a
to ani v rovine uvah "jak to udelat". Jak jsem jiz napsal - neni to 
kartograficka informace.





vop




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


Re: [OSM-ja] JOSM(10786)がなんか変

2016-08-16 Thread ribbon
On Tue, Aug 16, 2016 at 09:45:34AM +0900, Satoshi IIDA wrote:
> いいだです。
> 
> その関連でゆくと、、、
> 
> https://josm.openstreetmap.de/ticket/12282
> 
> スタイル指定に関するXML記述のサポートを終えた、とのこと、
> JOSMでカスタムスタイルを追加している場合、
> もしかしたら、そこで使われているスタイルが読み込めないことが理由で、
> イメージ画像が見当たらないエラーが出る、という状態になるかもしれないですね。

これか。

JA:Naming_Sample というモジュールを入れているのでそのせいかな。

でも、入っていない状況でも出るので、↑に対応していないところ(モジュール)が
まだあるのでしょうね。

ribbon

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


Re: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Dave F

+1

Also his use of is_in:* is also redundant when the boundary tag is used,

Dave F.

On 16/08/2016 13:25, Andy Allan wrote:

On 16 August 2016 at 13:11, Will Phillips  wrote:


Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not
consistent with other uses of the ref tag in OSM. Also, I agree that tagging
area values seems redundant, but perhaps doesn't do any harm in this case. I
do think at least, they should be retagged, perhaps to area:ha or
area:hectares?

No, they should be removed.

While it seems like tags like this do little harm, they encourage
future importers to follow the same path, and our database ends up
full of cruft. It's also off-putting to mappers, who might be scared
off from fixing the geometry of features since they don't know how to
recalculate the area.

There's no good reason to keep them.

Thanks,
Andy

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



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


Re: [Talk-GB] Defibrillator Mapping

2016-08-16 Thread Andy Townsend

On 16/08/2016 09:35, Robert Whittaker (OSM lists) wrote:

As in other areas, our mapping of Defibrillators in the East Midlands
doesn't seem to be very complete yet...


Thanks Robert.  The two nearest to me that I'm aware of are actually 
very new - they've only appeared within the last couple of months, so 
it's not too much of a surprise that they haven't been mapped yet.


Cheers,

Andy



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


Re: [Talk-GB] Defibrillator Mapping

2016-08-16 Thread Dave F

Hi

What a ridiculous response from South West Ambulance Services:

"There is a significant risk arising from a list of community
defibrillators appearing in the public domain..."

Clearly Mr Ken Wenman is unaware that 'community' & 'public' are one & 
the same.


They're even publicly tweeting the locations:
https://twitter.com/swasFT/status/566261258610278400

Dave F.

On 16/08/2016 09:35, Robert Whittaker (OSM lists) wrote:

Just to let you know, that I've now got another dataset in my
Defibrillator comparison tool athttp://robert.mathmos.net/osm/defib/
. East Midlands Ambulance Service has provided the locations of AEDs
that they know about, and these have now been imported into the tool.
As in other areas, our mapping of Defibrillators in the East Midlands
doesn't seem to be very complete yet...

Robert.

On 22 April 2016 at 14:43, Robert Whittaker (OSM lists)
  wrote:

It was suggested that trying to increase our mapping of public
Defibrillators would be a good think. After a bit of digging, it seems
that Ambulance Services typically maintain a list of locations, with a
view to informing people about them if a 999 call comes in nearby
where one might be useful.

The different services seem to take quite different views on these
lists. My local service (East of England) actively publicise their
list 
(http://www.eastamb.nhs.uk/Get-involved/Community-Public-Access-Defibrillators.htm)
on the grounds that raising awareness of the locations will make it
more likely that someone will know about and find a defibrillator in
an emergency. Other services have refused FOI requests on the (IMO
spurious) grounds that publicising the list will make thefts /
vandalism more likely, and out of date information may lead to people
wasting time in an emergency.

Anyway, I've taken the East of England list from
http://www.eastamb.nhs.uk/Get%20involved/CPADs/CPAD%20List.pdf  , and
done a comparison with the OSM data. A rough and ready tool can be
found athttp://robert.mathmos.net/osm/defib/progress/  for any other
locals who want to use it. We've got a small number of locations they
haven't, and some of their postcodes may not be quite right. But there
are a lot on their list that aren't mapped yet!

Regarding tagging, it seems that a lot of the cabinets have a
reference number on the outside, so I'd suggest recording that in the
ref=* tag. Also, I think a description of the location would be useful
(e.g. "Outside wall of McDonalds, facing Store 21") to help people
find the defibrillator when they need it. I've been putting something
like that in a location=* key.

In terms of getting more data, I've put in FOI requests to the East
and West Midlands Ambulance Services for starters, so we'll see what
line they take...



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


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-16 Thread Luca Meloni
>accuse politicizzate di leghismo/separatismo/razzismo
Nel caso direi che sarebbero accuse abbastanza ridicole o, per quanto riguarda 
il razzismo, chiari e gravi insulti. Per cui cose da ignorare e basta.

Comunque il solo nome italiano è arbitrario quanto e più di quello doppio, in 
quanto si decide che alcune istituzioni contano ed altre no "perché sì". 
Inoltre si ignorano l'utilizzo, sia nel parlato sia nei documenti scritti e 
digitali di comune, regioni e quant'altro, la cartellonistica ed in generale la 
"On The Ground Rule". Andiamo alla votazione, allora (anche se anch'io io direi 
che sarebbe più giusto un voto della comunità locale), ma propongo un 
"ballottaggio". Dopo il primo voto si ri-vota per le due possibilità più 
grosse. Ed i voti vanno argomentati.

Ciao,Luca

Il Martedì 16 Agosto 2016 11:11, Martin Koppenhoefer 
 ha scritto:
 

 

sent from a phone

> Il giorno 16 ago 2016, alle ore 09:06, Vittorio Bertola  ha 
> scritto:
> 
> L'unica soluzione che non crea arbitrarietà, flame infiniti e accuse di 
> parzialità (o peggio dà potenzialmente spazio ad accuse politicizzate di 
> leghismo/separatismo/razzismo...) è quella di usare anche per i place i soli 
> nomi ufficiali, in italiano e basta


allora è messo davvero male l'Italia, se si vuole la forza della legge e del 
governo centrale per tenere insieme tutti i vari pezzi? Se fosse davvero così 
sarebbe solo questione del tempo finché volerebbe tutto a parte, non si riesce 
tenere insieme perenne con la forza cosa vuole separarsi ;-)


ciao,
Martin 
___
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: [Talk-GB] ref:hectares on admin boundary, and non-responsive mapper

2016-08-16 Thread Will Phillips

On 15/08/2016 08:39, Colin Smale wrote:


Hi,

I noticed a number of new admin boundaries have been tagged with 
ref:hectares=* with the numeric value giving the area of the entity in 
hectares. This feels to me like an inappropriate use of "ref" and also 
redundant as the area can be calculated simply from the geometry 
anyway. When I queried this with the mapper (user alexkemp) via a 
changeset discussion [1] I got the following response:


"This is an automated response: sorry, but I'm too busy mapping too be 
able to spare the time to respond to you. Thank you for your interest 
in my mapping. -Alex Kemp"


Any thoughts about the tagging?

Any thoughts about engaging the user? There is also a discussion on 
another one of his changesets where he unilaterally diverged from the 
established tagging [2].


Colin

[1] http://www.openstreetmap.org/changeset/41449409

[2] http://www.openstreetmap.org/changeset/41371134

 _



Regarding the 'ref:hectares' tag, it does seem wrong to me. It's not 
consistent with other uses of the ref tag in OSM. Also, I agree that 
tagging area values seems redundant, but perhaps doesn't do any harm in 
this case. I do think at least, they should be retagged, perhaps to 
area:ha or area:hectares?


Will

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


Re: [Talk-it] Info su livelli mappa

2016-08-16 Thread Martin Koppenhoefer


sent from a phone

> Il giorno 16 ago 2016, alle ore 13:55, Pko .  ha scritto:
> 
> Ad esempio per migliorare la consultazione della mappa perché non inserire i 
> nomi delle vallate alpine o quello delle regioni/dipartimenti, ecc.?
> Oppure mettere in evidenza il nome dei passi alpini principali?


per suggerimenti di aggiungere elementi sulla mappa "principale " occorre 
chiedere alla squadra dello stile qui:
https://github.com/gravitystorm/openstreetmap-carto

Ci sono già richieste per alcune delle cose di cui parli.

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


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-16 Thread Paolo Monegato

Il 16/08/2016 09:06, Vittorio Bertola ha scritto:
Scusa se reintervengo, ma allora non capisco proprio il senso della 
tua posizione. Una settimana fa mi hai detto che però secondo te il 
doppio nome si può mettere per il sardo ma non per il piemontese, 
perché solo la prima lingua è tutelata dalla legge 482/99... ma questa 
è esattamente una distinzione imposta dall'alto per regola nazionale, 
proprio come quella per cui il nome ufficiale è solo in italiano.


Occhio che in un caso si tratta del tag name sull'entità amministrativa, 
nell'altro si parla del tag sul place...
Fosse per me metterei i nomi dappertutto, senza far favoritismi 
linguistici. Ma mi rendo conto che una posizione più condivisibile sia 
proprio quella di discriminare secondo la normativa, lasciando alle 
comunità locali delle zone tutelate la decisione su come rappresentare 
la loro realtà.


Solo che questa linea porta al caos, perché a quel punto le lingue non 
ufficiali effettivamente usate sul territorio sono molte (in molti 
Comuni anche piccoli ci sono comunità immigrate che sono ben più 
numerose dei parlanti della lingua locale tradizionale, ufficiale o 
meno che sia: su che base le vuoi discriminare?), e perché non ho 
capito chi definisce quale sia la "comunità locale" che può decidere 
quali lingue includere: gli utenti della Regione? del Comune? 
dell'area etnica tradizionale, es. le vallate occitane?


Difficile che gli emigrati usino un toponimo differente da quello 
ufficiale. Paesini sconosciuti hanno difficilmente degli esonimi.


Nel caso specifico sostengo che la decisione la debba prendere la lista 
regionale sarda, in quanto rappresentante della comunità locale dei 
mappatori.



ciao
Paolo M

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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Martin Koppenhoefer


sent from a phone

> Il giorno 16 ago 2016, alle ore 12:52, Richard  ha 
> scritto:
> 
> Übrigens... wer hat hier sein vollstes Vertrauen in ein "Deutsche Telekom 
> Root CA"?


+1, Amerikaner bezieht sich auch auf deren Alliierte und sonstwie Hörige (die 
"westliche Welt"), und wer da Bedenken hat, der kann ja in Russland oder China 
oder  sein Zertifikat ausstellen lassen :) Eigentlich gibt es keine 
vertrauenswürdigen Zertifikate außer denen, die man sich selbst generiert ;-P

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[Talk-it] Info su livelli mappa

2016-08-16 Thread Pko .
Ciao a tutti,
Vorrei sapere se è possibile agire anche sulle informazioni contenute dalla
mappa ai vari livelli di ingrandimento. Ad esempio per migliorare la
consultazione della mappa perché non inserire i nomi delle vallate alpine o
quello delle regioni/dipartimenti, ecc.?
Oppure mettere in evidenza il nome dei passi alpini principali?

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


Re: [OSM-talk-ie] History of Townlands - What can we put on a slide?

2016-08-16 Thread Stephen Roulston
Below is paraphrased (and a little extended) from the general introduction in 
the Place-names of Northern Ireland series published by the Northern Ireland 
Place-name Project, Department of Celtic, Queen’s University Belfast

Earliest place names are found in mainly Irish language material, sometimes in 
Latin, from 7th or 8th centuries. This is them written for the first time - 
they are much older than that. The Irish Annals, started about 550AD, had many 
place names particularly of tribes, settlements and topographical features. 
Some of the legends recorded in the Annals give explanations of place names. 
For example, the triumphal charge around Ireland of the Brown Bull at the end 
of the Tain Bo Cuillaigne is said to have generated many names. The 
townland/region of Athlone or Áth Luain was named from the loins (luan) of the 
White-horned bull that the Brown Bull killed there. Some must be very ancient. 
A number relate to Maeve, who originated as a Mother Earth fertility god. There 
is Ballypitmaeve, close to Glenavy in Co.Antrim, for instance, where the 
fertility reference is very clear.

We cannot know how old townland names are, but it is clear that they are very 
ancient, and they were present, and probably already very old when written 
records began in Ireland. Incidentally, it is ironic that it took the 
Plantation in the 17th Century to gather the names in a systematic way. It is 
also curious that, while Sir William Petty, who surveyed much of Ireland, said 
that Irish place names were ‘uncouth and unintelligible’ and that ‘where they 
cannot be abolished’, they should be translated into English, the planters in 
most cases retained the original names. 


> On 15 Aug 2016, at 19:14, Killian Driscoll  wrote:
> 
> On 15 August 2016 at 20:01, Killian Driscoll  >
> wrote:
> 
>> On 15 August 2016 at 19:17, Rory McCann  wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>> 
>>> Hiya,
>>> 
>>> As yous know, myself and Dave are doing a talk about townlands at the
>>> global OSM conferences, State of the Map, in Brussels in September.
>>> 
>>> Can anyone tell me more about the history of townlands? Something nice
>>> to add to a slide?
>>> 
>> 
>> See this which talks about boundaries - Baronies etc (you could say the
>> townlands line up with the baronies) - based from the Iron Age
>> https://www.academia.edu/3206604/Kingship_and_
>> Sacrifice_Iron_Age_Bog_Bodies_and_Boundaries if you Google the bog bodies
>> in images you should get some you can use
>> 
> 
> This pdf talks a bit about the history and the naming in the 19C etc
> Landscape representation: Place and identity in nineteenth-century ordnance
> survey maps of *Ireland*
>  >
> A Smith - Landscape, Memory and *History*, Pluto Press: London, 2003 -
> academia.edu 
> 
>> 
>> 
>> 
>> 
>>> I've heard that townlands were mentioned in the Táin Bó Cúailnge. Can
>>> anyone tell me more about this?
>>> 
>>> I looked at [the scans of the Lebor na hUidre (Book of the Dun
>>> Cow)](https://www.isos.dias.ie/master.html?https://www.isos.
>>> dias.ie/libraries/RIA/RIA_MS_23_E_25/english/index.html?
>>> ref=http://www.isos.dias.ie/libraries/RIA/english/ria_menu.html?ref=),
>>> is anyone able to point to a word on a page and say "This is townland
>>> X in Co. Whatever". (I tried it myself, but er, it's Old Irish). It
>>> would impress to the Americans & other Europeans that the townlands
>>> are ancient, and a part of our history, heritage and culture. We
>>> didn't spend all these years mapping them just cause.
>>> 
>>> Any hints?
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2.0.22 (GNU/Linux)
>>> 
>>> iQEcBAEBAgAGBQJXsfkoAAoJEOrWdmeZivv2NkoH/2dD/XUWA/3EDX/t04G4C+r+
>>> FYzLmLgkGIplClf7w1Ux0wB/6ZYgtht6dvZ8DQvRaG6YxbREZXA40HLfcsLoSru2
>>> 1/eAOZeEReft7oQjugsZs+uPUNzX01PZ4bk7GTZ12/bfCDwcdAX8lAJhwIGl+Lf2
>>> ZWKaVCNq5UmCZtUJvTs/3u5YX3nVrYorjwkQ2+X6/T/Y/jN71kxen1vLrMNJRiQ+
>>> 7oEAesQwUT6Vj87mMKJ2Iw3N/6LG6TxwfHSn2etF7Syb4geOV/K6kjPblcQ1usQ5
>>> PBSB2OB9h5Apav9QyLIq+u/P1NILDOzUJbSAv/qmyMSUBC3IArhw1hohgGum938=
>>> =1GX2
>>> -END PGP SIGNATURE-
>>> 
>>> ___
>>> Talk-ie mailing list
>>> Talk-ie@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ie
>>> 
>> 
>> 
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie

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


Re: [Talk-cz] 5x červená

2016-08-16 Thread Petr Holub
>   Coz mne jeste pripomina jednu vec: budme opatrni s temi navrhy na zmeny
>   znaceni. Pri dovolenkovem mapovani v okoli Kremesniku (Pelhrimova) jsem
>   narazil na to, ze uz nektere trasy postradaji tag kct_*, coz muze v 
> soucasnem
>   stavu cinit renderum potize (napr. pro nasi mtbmap.cz - byt tam jeste 
> cekam
>   na overeni, protoze Martin ted resi problem s nastroji v ramci updatu 
> dat).
>   Takze pokud mame navrh na nove znaceni zalozene pouze na osmc:symbol, 
> melo
>   by byt jasne, ze je to "jen" navrh a taky by melo byt jasne receno, kdy 
> se
>   tento navrh preklopi do produkcniho stavu, aby se tedy daly zacit 
> upravovat
>   renderery.
> 
>   Petr
> 
> 
> 
> 
> Toto je Petře IMHO dávno překonaný problém. Renderery se dávno na tag 
> kct_barva=* nespoléhají,
> resp. jej ignorují. Konkrétně MTBmap též.

Uz mi to Martin taky psal - takze by bylo dobre to jeste pro jistotu
overit na nejake takove trase. Ted jede novy update dat a snad by to do
konce tydne melo dobehnout, takze pak bude prilezitost to zkontrolovat.

Ale v kazdem pripade plati, ze bychom meli rict, kdy se ten navrh preklopi
do provozniho (akceptovaneho) stavu, kterym se maji vsichni ridit. Protoze
zatim je to jen navrh a vsichni by jeste meli pouzivat to stare znaceni. 

Petr


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


Re: [Talk-cz] Zpracování vrstevnic pro mapy

2016-08-16 Thread Lukáš Karas
Děkuji za shrnutí. Můj problém spočívá právě v tom dávkovém zpracování. 
SRTMv4 vyžaduje pro stažení ověření účtem, což jsem ještě schopen do Srtm2Osm 
dopsat. Ale pokud i SRTMv4 obsahuje "černá místa" v nějaké větší míře, bylo by 
vhodné provést nějakou interpolaci... 

A s tím už se mi dělat nechce a raději bych sáhnul po hotovém řešení ;-) 
Ale o žádném nevím. Zároveň vidím webové mapy které mají ṕerfektní 
vrtevnice... 

Lukáš

Dne úterý 16. srpna 2016 10:05:25 CEST Jakub Sykora napsal(a):
> Ahoj,
> 
> záleží, odkud čerpáš SRTM data a zda jsou tam interpolované voidy. V
> surových datech toho dost chybí.
> Také je dobré se do těch zdrojových dat podívat, jak to vypadá v těch
> oblastech, kde selhal převod na vrstevnice, vypadá.
> 
> Jedna z možností je SRTM v4 ze http://srtm.csi.cgiar.org/
> Udělali tam hodně práce na kvalitě dat. Ale jsou to pouze 90m data (3
> vteřinová)
> 
> Pokud to chceš méně hranaté, můžeš zkusit jednovteřinová data, ale opět
> platí, že je potřeba v datech vyplnit voidy nějak rozumně, protože i tam
> nějaké jsou. Viz https://lta.cr.usgs.gov/SRTMVF a SRTM 1 Arc-Second
> Global a stahova tmožno přes http://earthexplorer.usgs.gov/
> 
> K
> 
> Dne 16.8.2016 v 09:37 Lukáš Karas napsal(a):
> > Ahoj, měl bych dotaz na lidi kolem projektu openstreetmap.cz:
> > Vrstevnice které jsou součástí map si zpracováváte sami, nebo stahujete
> > předpřipravené z nějaké služby?
> > 
> > Zkoušel jsem do svých mobilních map (postavených nad OSM Scout knihovnou)
> > přidat vrstevnice, použil jsem Srtm2Osm tool pro vytvoření vrstevnic z
> > SRTMv2 dat od Nasa. Vše vypadalo vpořádku, dokud jsem nezkusil Alpy, kde
> > jsem narazil na tyto podivnosti:
> > http://www.karry.cz/files/ContourLines_bug.png
> > 
> > Na OSM wiki jsem se dočetl že SRTM data mají tento problém na místech kde
> > byl sníh :-( Chtěl jsem vyzkoušet použít novější data (SRTMv3), ale pro
> > ten jsem zatím nenašel funkční nástroj...
> > 
> > Když se podívám na openstreetmap.cz, třeba na vrstvu zimní sporty tak
> > tento
> > problém se ve vrstevnicích nevyskytuje...
> > 
> > Poradíte prosím jaký zdroj a nástroje použít pro dokonalé vrstevnice?
> > 
> > Díky, Lukáš
> > 
> > 
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] kvartální piva

2016-08-16 Thread honny
Zdar,

Dne 16. srpna 2016 11:25 Petr Vozdecký  napsal(a):
> ...no já už jsem si to do svého kalendáře dal.

taky tak. :)
Co se tyka Brna a terminu v pracovnim tydnu, nemam s tim problem a prijdu rad.



h.

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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Richard
On Tue, Aug 16, 2016 at 11:28:07AM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > Il giorno 16 ago 2016, alle ore 09:52, lars lingner 
> >  ha scritto:
> > 
> > Die richtige Lösung ist aber auf dem Server ein gültiges Zertifikat zu
> > hinterlegen.
> 
> 
> ein Zertifikat dass keine Warnung generiert ist nicht "richtiger" als eins 
> mit Warnung, es wurde lediglich von einer CA ausgestellt, die im Browser als 
> vertrauenswürdig voreingestellt ist, aber solche CAs wurden in der 
> Vergangenheit auch schon öfters kompromittiert, sind zudem oft amerikanische 
> Firmen und von daher aufgrund der dortigen Rechtslage per se nicht 
> vertrauenswürdig.

[wildly OT]

... wenn das nur die amerikanischen Firmen wären. Wenn man sich das root CA 
Verzeichniss
von den Browsern/Betrbiebssystemen ansieht sind dort Behörden/Firmen aus 
etlichen für 
Folter und schlimmeres berüchtigten Länder vertreten.

Das Fatale - jede dieser CAs kann nicht nur für ihre kleine Absurdistanenklave 
"gültige"
Zertifikate generieren sondern jedezeit unbemerkt(*) ein gültiges fake 
Zertifikat für Google,
OSM und die deutsche Sparkasse ausstellen.

Übrigens... wer hat hier sein vollstes Vertrauen in ein "Deutsche Telekom Root 
CA"?

Richard

(*) es besteht neuerdings die Pflicht ausgestellte Zertifikate in einem globalen
Log einzutragen kann aber dauern bis das auch funktioniert

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


Re: [Talk-ca] Mapping exit numbers and destinations in Canada

2016-08-16 Thread James
I dont see why not if we are making the map follow the standards, any
misstagging should probably be corrected

On Aug 16, 2016 5:21 AM, "Manohar Erikipati"  wrote:

> Hi everyone,
>
> Thank you Harald, James and Kevin for your replies. We currently follow the 
> proposed mapping methods in the Wiki [1] James had mentioned. We have 
> observed that there are name tags given for junction nodes[2] in which 
> destinations were given. Is this a previously agreed tagging method to render 
> destinations on nodes or is there any particular reason the name tags were 
> given to the junction nodes? Is it okay if we delete these name tags on 
> junction nodes now that we are giving destination, destination:street tags to 
> the  exit ways?
>
>
> Cheers,
>
> Manohar
>
>
>
> 1. http://wiki.openstreetmap.org/wiki/Exit_Info
> 2. 
> https://cloud.githubusercontent.com/assets/8921295/17693961/387f991c-63bf-11e6-9a77-988221f47c41.png
>
>
>
>
> On Thu, Aug 11, 2016 at 6:23 PM, Kevin Farrugia 
> wrote:
>
>> Yes - recently bootprint, andrewpmk, and I have been changing and
>> correcting the name tags to destination in Ontario along the 400-Series
>> highways. If you see a ramp/link that is named, it's fine to change it over
>> to destination or correct a problem you find with it.
>>
>> On Aug 11, 2016 8:38 AM, "Harald Kliems"  wrote:
>>
>>> Hi Manohar:
>>> It is my understanding that including destinations in the name is an
>>> artifact of people tagging for the renderer (and/or tagging destinations at
>>> a time before there was an established tagging scheme). If you search
>>> through the talk-ca archives, you should be able to find some discussions
>>> on the topic.
>>>  Harald.
>>>
>>> On Thu, Aug 11, 2016 at 7:25 AM Manohar Erikipati 
>>> wrote:
>>>
 Hello everyone!

 Turn restriction sprint was met with an amazing response! We loved
 working with you all on adding turn-restrictions in Canada. We appreciate
 the timely help and suggestions we got which helped us add correct
 restrictions and to also maintain the quality of data we were adding on to
 OpenStreetMap. We hope that this support will continue further, as we are
 embarking on mapping exit numbers and destinations in the same 5 cities of
 Canada.

 We have made an easier workflow [1] with tasking manager [2] for adding
 exit and destinations. We would like your assistance, participation and
 continued involvement in the project. We have captured the details of this
 task here [3].

 After a preliminary look into the already mapped exit numbers and
 destinations, we have these observations:

 - We noticed that `destination` (places, cities) and `destination:ref`
 (highways) tags are being added to the nodes of exits as `name` tags.
 - Few exit nodes have destinations given in the `ref` tag.
 - The `destination:street` (towards streets, avenues, boulevard, rue)
 tags were not being used.

 To begin with, we have one question: Destinations given in the name tag
 of nodes is not usual protocol for adding these tags. We want to make sure
 whether it is valid or if we could change these tags to the `destination`
 based tags accordingly. For more details, here's the complete breakdown
 [4]. To reach out to more audience, we have captured this in a OSM diary
 post [5]. We would like to hear from the community about the agreed method
 of mapping exit numbers and destinations to take this forward.

 1. https://gist.github.com/manoharuss/3a1b4f640aaf2c052365fcb1ddb09beb
 2. http://cfn-tasking-manager-staging-vpc-387856624.us-east-1.e
 lb.amazonaws.com/project/20
 3. https://github.com/mapbox/mapping/issues/220
 4. https://gist.github.com/poornibadrinath/9333f1489732c32c3ffa
 dd58e3068b7e
 5. https://www.openstreetmap.org/user/poornibadrinath/diary/39246

 Thank you!

 Cheers,
 Manohar Erikipati
 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ca

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


Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Daniel Koć

W dniu 16.08.2016 12:04, Hakuch napisał(a):


as this new-server-software project will take some time. How do you
think about hijacking another country-subforum? There are a lot where 
no

one is active with only very few posts. I would accept it as temporary
solution.


No need to invade Uruguay or Venezuela (both low volume with last 
activity in March)... ;-P I think general chat is the best place to 
start, since it is also low volume and may be used for things which have 
no better place to be discussed - especially with subjects like 
"[Iceland] National parks":


http://forum.openstreetmap.org/viewforum.php?id=9

If Lambertus ever wake up, it will be just a matter of pushing them to a 
new subforum, so nothing would be lost and no fragmentation will occur. 
If not, it will still be easy to do on a new server.


It would be a pity to not start community work just because there is no 
optimal place!


--
"Low, low, low..." [M. Kempa]

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


Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread jzvc

Dne 16.8.2016 v 11:21 Petr Vozdecký napsal(a):

mapa pokrytí signálem IMHO nepatří do OSM, protože se jedná o přiliš
dynamickou informaci, navíc s nepříliš vypovídající informací. Co to je
"pokrytí"? Je to izočára vyjadřující -40 dBm? Nebo -60 dBm? Ve kterém
kmitočtovém pásmu? Bude vytvořena na základě měření (reálný stav k
okamžiku měření), nebo jako teoretická hodnota (výpočet na základě
ideálního stavu známých či předpokládaných hodnot a veličin)?

Ještě jednou - tato informace je natolik dynamická (řádově
mnoho-mnohonásobně dynamičtější, než běžně mapované prvky jako cesty,
objekty...) a současně relativní ve vztahu k zobrazované informaci (co
vlastně zobrazuje? viz otázka síly signálu a pásma + otázka citlivosti a
selektivity přijímače terminálu - tedy mobilu), že se může možná hodit
jako externě renderovaná bitmapová vrstva, nicméně v nativních OSM
datech by teoreticky mohly být pouze hodnoty pro její výpočet (lokace
BTS+výška ANT+ziskANT+RFvýkon+útlum
vedení+azimut+elevace+horizontální_vyzařovací_úhelANT+vertikální_vyzařovací_úhelANT+dynamická_data_útlumu_prostředí...),
který (pseudoodborníci prominou) je nakonec ve výsledku jen snůškou
teoretických hodnot použitých po patřičné účelové interpretaci pro
marketing provozovatele služby. Mj. také proto, že (a pseudoodbornící
opět prominou) skutečnost, že v daném místě je teoreticky signál vůbec
neznamená, že se uživateli s konkrétním přístrojem (opět výkon, typ
antény...) podaří sestavit hovor či "jen" dostat data. Ono pokrytí na
downlinku je jedna věc, k mobilní komunikaci je potřeba i ten uplink...

No a ještě jeden argument - mapa pokrytí komerční službou není
kartografickou informací - je to trochu podobné, jako "mapa pokrytí
služeb rozvážky jídla společnosti XYZ"...



Cus, v OSM stejne nemas data ani na to, abys udelal nejakej hypotetickej 
vypocet. Nemas informace o terenu, nemas informace o prekazkach, i pokud 
budes mit vysku budov, tak mas relativni, ale ne absolutni ...


Takze defakto jediny co muzes udelat je namalovat kolem nejaky "kolecka" 
(v pripade ze mas vykony a smery anten tak "sisoidy"), jak by to asi 
vypadalo, kdyby kolem nebylo nic.


Hypoteticky by bylo mozny udelat neco jako bodovy pole mereni - kde bys 
vrazil node na tema "tuhle sem stal a zmeril tam tyto hodnoty", coz by 
pri dostatecny hustote byla jiste zajimava informace a z toho by se dala 
udelat mapa realneho pokryti.


Jenze to pak muzem stejne merit i TV/Radio/ a nemyslim si, ze by 
toto melo byt primo soucasti mapy. To neznamena, ze by osm nemohla 
provozovat neco podobnyho jako vedlejsi projekt - ale pak by bylo fajn, 
kdyby to bylo univerzalni => ne jen bts, ale vse co se da chytat.


BTW: Treba RLP Ruzyne se da chytat klidne i v okoli Brna ...



vop


-- Původní zpráva --
Od: Janda Martin 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 8. 2016 10:38:31
Předmět: Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314


Osobne bych zvolil o neco drazsi SW na vypocet signalu: "RadioLab
verze 4" :-)


http://www.crcdata.cz/index.php/radiokomunikacni-sw/rada-rl4/radiolab-4/rl4-site

Martin

PS Pro upresneni: Pracuji na vyvoji systemu RadioLab


- Original Message -
From: "Michal Poupa" 
To: "OpenStreetMap Czech Republic" 
Sent: Tuesday, August 16, 2016 9:54:48 AM
Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

Na počítání signálu byl šel použit sw Radiomobile (
http://www.cplus.org/rmw/english1.html )
ale moc nechápu k čemu by to na OSM bylo...

16. 8. 2016 v 9:24, Janda Martin :

 > Dobry den,
 >
 > pridavani BTS do OSM bych zatim nedelal.
 > *) v OSM chybi stale spousta domu a kominu na kterych jsou BTS
umisteny. Cast dat je posunuta
 > *) Na BTS stanovistich se meni parametry
 > *) OSM data jsou spise staticka.
 >
 > *) dle meho nazoru mapa pokyti signalem rozhodne nepatri do OSM.
 > Navic bez parametru primo od operatoru/CTU nelze spocitat. Navic
se jedna o relativne dynamickou zalezitost
 >
 > --- spis bych navrhl zvysit kvalitu dat pro CR
 > *) doplnit kominy
 > *) jak to vypada s databazi stromu? (neco tu letos probehlo)
 > *) je potreba zjistit aby nova data nebyla vkladana do OSM posunuta
 > *) oprava starych silnich a ploch ktere jsou posunute az o
desitky metru
 > *) omezit rucni prekreslovani z leteckych fotek ktere nemaji
kompenzovane zkresleni
 >
 > --- pred editovanim detailu (zahradky, ploty, cesty, ...)
 > 1) v oblasti importovat budovy RUIAN
 > 2) importovat RUIAN lands
 >
 > *) pak teprve dokreslit detailni objekty. Dost casto se stava ze
detily jsou dokreslene posunute a velmi zjednodusene
 >
 > Martin
 >
 > - Original Message -
 > From: "Pavel Machek" 
 > To: 

Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Hakuch
On 16.08.2016 11:45, Jóhannes Birgir Jensson wrote:
> Þann 16.08.2016 00:24, Nicolás Alvarez reit:
>> ArchiveTeam.org is already doing this HTML backup.

> With access to forums you only see after login?

The scraping is not about a html-backup. What we would need for
transfering the old posts into a new forum software is the raw DB Data.
If we cant get them from the server itself, we have to reproduce it from
the html view. My script is able to do that.

> As for "no panic" then we've got several projects cooking in Iceland
> after a beneficial annual meeting but we've not launched them yet
> because we don't want to fragment any more than strictly needed so the
> forum issue has been plaguing us. We could set up our own forum and go
> from there but that is counter-productive in the long run.

as this new-server-software project will take some time. How do you
think about hijacking another country-subforum? There are a lot where no
one is active with only very few posts. I would accept it as temporary
solution.


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


Re: [Talk-cz] 5x červená

2016-08-16 Thread Petr Vozdecký


-- Původní zpráva --
Od: Petr Holub 
Komu: 'OpenStreetMap Czech Republic' 
Datum: 13. 8. 2016 7:15:15
Předmět: Re: [Talk-cz] 5x červená

"> > Tedy závěrem tohoto postu je spíše otázka, co s tím? Tedy co se
> > splýváním tras stejné barvy, když si z nějakého (nota bene mnou
> > vymyšleného) důvodu nemůžeme pomoci ani vygenerovanou značkou (ikonou)
> > v mapě? A jak v takovém případě pouhým pohledem do mapy poznat, že jde
> > o vozíčkářskou trasu? Není tady navržené pravidlo "nemá značku v
> > terénu, nemá ji mít ani v mapě" kontraproduktivní? Na mapy.cz
> > https://mapy.cz/s/XzJZ se s tím vyrovnávají tak, že vozíčkářskou trasu
> > vykreslují jako růžovou linii s ikonkou vozíčkáře v barvě trasy.
> Ty vozíčkářské trasy mají taky své barvy. KČT je vykresluje vždy červěně
> čerchovaně. Viz
> http://www.labskastezka.cz/ladmin/soubory/labskastezka/File/konference_
LIT/03_Vozickarske_tras
> y_KCT.pdf
> 
> IMHO to značené je. Je úplně jedno že jenom rozcestníky, ale značené to 
je.

Souhlas: to, ze chybi pasove znaceni je jedna vec, ale v principu to
znacene v terenu je (aspon) temi rozcestniky."
Jistě. Zde jsem se asi dopustil nepřesnosti v tom, co jsem měl na mysli. 
Nezpochybňoval jsem otázku, zda to mapovat (tedy zda vytvářet relaci 
relation; type=route; route=wheelchair; wheelchair=major). Směřoval jsem k 
tomu, zda tagovat v té relaci i osmc:symbol=* když za značka NENÍ FYZICKY v 
terénu. Navazoval jsem na svůj vlastní dřívější návrh, že tag osmc:symbol=* 
by se měl používat jen tam, kde ta značka v terénu opravdu je (viz naučné 
stezky tagované a vykreslené pomocí osmc:symbol=green:white:green_backslash 
kde ale v terénu ta značka prostě není a nelze podle ní jít).

No a teď jsem si uvědomil, že:

1) Wiki u osmc:symbol značku "wheelchair" ani nemá... zatím...


2) není pravda, že v uvedeném případě ta značka v terénu uvedena není. Ona 
tam je , je zřetelně na rozcestnících a pomocných směrnících v odbočkách, 
jen prostě není každých 50 m jak na turisťárně v lese. Učinil jsem špatný 
závěr a tím je po "problému"





Tedy - z toho plyne moje doporučení - doporučit či prosadit značku color_
wheelchair pro tag osmc:symbol, tedy např: osmc:symbol=red:white:red_
wheelchair (růžovou jsem tam pro vykreslovanou linii nepsal, jednak v 
základní specifikaci není - viz http://wiki.openstreetmap.org/wiki/Key:osmc:
symbol a hlavně předpokládám, že renderer by si určil nekolizní barvu sám na
základě tagu z relace route=wheelchair a v případě, že by vykresloval JEN 
tyto wheelchair trasy, tak mu pomůže pro hezké vykreslení skutečná 
odpovídající barva).




Pozn: na OpenStreetMap.cz v turistické vrstvě od Petra Vejsady (Poloha.net) 
je grafický symbol vozíčkáře vykreslen - v datech to ale není zavedeno 
správně jako relace, ale je to "starý" tag na cestě kct_red=wheelchair. 
Poloha.net to tedy umí renderovat, otázka je, zda i na relaci a zda i via 
nějakou podobu tagu osmc:symbol=*




"

> No, ruzova linie s ikonou vozickare zni jako dobre reseni pro renderer.
> 
> V datech se proste uvede ze to je vozikarska trasa, a renderer se dle toho
> zaridi, ne?

Presne - optimalizaci zobrazovani v rendereru bych diskutoval separatne
od dat.

Coz mne jeste pripomina jednu vec: budme opatrni s temi navrhy na zmeny
znaceni. Pri dovolenkovem mapovani v okoli Kremesniku (Pelhrimova) jsem
narazil na to, ze uz nektere trasy postradaji tag kct_*, coz muze v 
soucasnem
stavu cinit renderum potize (napr. pro nasi mtbmap.cz - byt tam jeste cekam
na overeni, protoze Martin ted resi problem s nastroji v ramci updatu dat).
Takze pokud mame navrh na nove znaceni zalozene pouze na osmc:symbol, melo
by byt jasne, ze je to "jen" navrh a taky by melo byt jasne receno, kdy se
tento navrh preklopi do produkcniho stavu, aby se tedy daly zacit upravovat
renderery.

Petr"



Toto je Petře IMHO dávno překonaný problém. Renderery se dávno na tag kct_
barva=* nespoléhají, resp. jej ignorují. Konkrétně MTBmap též.

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


Re: [OSM-talk] Forum admin(s) wanted

2016-08-16 Thread Jóhannes Birgir Jensson

Þann 16.08.2016 00:24, Nicolás Alvarez reit:

2016-08-15 21:13 GMT-03:00 Daniel Koć :
If we have no current backup available, I think it would be good to 
have a
script harvesting all the entries even just via plain HTML, with 
publishing
date, username and user id, so we could recreate it more or less on 
the new
server. Old backup may have some value, but most of the time fresh 
content

is what really matters.


ArchiveTeam.org is already doing this HTML backup.


With access to forums you only see after login?

As for "no panic" then we've got several projects cooking in Iceland 
after a beneficial annual meeting but we've not launched them yet 
because we don't want to fragment any more than strictly needed so the 
forum issue has been plaguing us. We could set up our own forum and go 
from there but that is counter-productive in the long run.


We would like the matter to be resolved shortly, pumping up enthusiasm 
and belief in projects is hard work and harder when the organizational 
tools we wanted to adhere to are broken (in this case in a logistical 
more than technical way).


--Jóhannes

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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Martin Koppenhoefer


sent from a phone

> Il giorno 16 ago 2016, alle ore 09:30, Carl von Einem  ha 
> scritto:
> 
> Man kann jetzt unter "Erweitert" eine "Ausnahme hinzufügen...", wenn man sich 
> überlegt, ob das selbst signierte (also nicht bereits im Browser hinterlegte) 
> Zertifikat bzw. dessen Aussteller vertrauenswürdig ist und vor allem: ob man 
> sensible Daten überträgt.


Vor allem nur dann das Zertifikat hinzufügen, wenn man sich sicher ist, dass es 
vom Fossgis bzw. OSM kommt und nicht z.B. von einem Angreifer, der den DNS 
Eintrag gehackt, die Seite nachgebaut und den traffic umgeleitet hat, und jetzt 
nur noch darauf wartet, Eure OSM loginDaten abzugreifen ;-)


Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-cz] kvartální piva

2016-08-16 Thread Oto Kaláb

Zdarvím,
nejsem nějaký super-aktivní mapper, ale OSM fandím, data využívám i v 
rámci výuky a myšlenku šířím. Rád se zapojím do ostravských dýchánků 
(jen ten první termín 7.9. budu nejspíš mimo).

Oto

Dne 16.8.2016 v 08:16 Zbyněk Datinský napsal(a):
Za ostravu a široké okolí se mnou počítejte. Jen bych tam nerad seděl 
u piva sám :-)

datin

-- Původní zpráva --
Od: Ladislav Nesnera 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 8. 2016 8:08:25
Předmět: Re: [Talk-cz] kvartální piva


Myšlénku mám za dobrou, klíč za geniální (y) a reakce za
překvapivě nulové.. :-OOO



On 09/08/16 00:16, Petr Vozdecký wrote:

ahoj,

navazuji tímto na nějakou debatu dříve, myslím na SotMu...?
což konec konců není ani důležité:

diskutovali jsme potřebu zavést do regionálních setkání (čti:
sleziny u piva) jakousi pravidelnost - ne snad z důvodů nutné
pravidelnosti jako takové, ale spíše proto, abychom si
ulehčili nekonečné potíže s hledáním ochotných svolavatelů a
pak vhodných termínů a nakonec i ideálních míst..., prostě
pravidelnost proto, aby ta setkání proběhla bez závislosti na
malicherných okolnostech a současně i proto, aby je bylo možné
lépe (dlouhodobě) ze strany účastníků plánovat.

Tedy (po předchozí konzultaci s aktivními účastníky brněnských
slezin) navrhuji zavést pravidlo ve formě kvartální sleziny a
to ve třetím měsíci kvartálu (vyhneme se tím prázdninám) a to
na jeho začátku (vyhneme se tím Vánocům). Např. první středa v
měsíci (to je ten den, co houkají sirény, může to být hezká
upomínka, kterou Vám ani Google nezorganizuje :o). Je jedno,
zda se to vžije jen pro Brno, nebo se najdou i jiné lokality.
Každopádně myslím, že by bylo fajn z každé sleziny udělat i
nějaký stručný report, protože prakticky vždy tam padne něco
podnětného.

4 setkání ročně nejsou až tak moc, ne? Letos bychom stihli
ještě dvě a to 7.9. a 7.12. ...

Předem díky za reakce

vop

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


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



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


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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Martin Koppenhoefer


sent from a phone

> Il giorno 16 ago 2016, alle ore 09:52, lars lingner  
> ha scritto:
> 
> Die richtige Lösung ist aber auf dem Server ein gültiges Zertifikat zu
> hinterlegen.


ein Zertifikat dass keine Warnung generiert ist nicht "richtiger" als eins mit 
Warnung, es wurde lediglich von einer CA ausgestellt, die im Browser als 
vertrauenswürdig voreingestellt ist, aber solche CAs wurden in der 
Vergangenheit auch schon öfters kompromittiert, sind zudem oft amerikanische 
Firmen und von daher aufgrund der dortigen Rechtslage per se nicht 
vertrauenswürdig. Sie haben lediglich mehr politische Macht und Geld, um in den 
Browser per default eingebaut zu werden. Es ist nur die Frage, gegen wen man 
sich schützen will, Verbrecher haben vermutlich wenig Interesse daran, 
auszuspionieren wofür man sich interessiert und welche Kartenausschnitte man 
sich ansieht, wir sind ja keine Homebanking seite.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-cz] kvartální piva

2016-08-16 Thread Petr Vozdecký
...no já už jsem si to do svého kalendáře dal. Teď by se mi hodilo najít 
nějaké pivoleadery v Praze a Ostravě (a na jiných místech) a dodnout se na 
tom, v jaké podobě to provážeme - minimálně si představuji nějaké "heslovité
zápisy diskutovaných myšlenek..."

vop


-- Původní zpráva --
Od: Jan Martinec 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 8. 2016 9:04:01
Předmět: Re: [Talk-cz] kvartální piva

"

Hmm, nejak to propadlo do hlubin mailboxu. Za mne super napad - obvykle jsem
v Praze a okoli.

Honza Piskvor Martinec



Dne 16. 8. 2016 8:08 dop. napsal uživatel "Ladislav Nesnera" :
" 

Myšlénku mám za dobrou, klíč za geniální (y) a reakce za překvapivě nulové..
:-OOO





On 09/08/16 00:16, Petr Vozdecký wrote:

"ahoj,

navazuji tímto na nějakou debatu dříve, myslím na SotMu...? což konec konců 
není ani důležité:

diskutovali jsme potřebu zavést do regionálních setkání (čti: sleziny u 
piva) jakousi pravidelnost - ne snad z důvodů nutné pravidelnosti jako 
takové, ale spíše proto, abychom si ulehčili nekonečné potíže s hledáním 
ochotných svolavatelů a pak vhodných termínů a nakonec i ideálních míst..., 
prostě pravidelnost proto, aby ta setkání proběhla bez závislosti na 
malicherných okolnostech a současně i proto, aby je bylo možné lépe 
(dlouhodobě) ze strany účastníků plánovat.

Tedy (po předchozí konzultaci s aktivními účastníky brněnských slezin) 
navrhuji zavést pravidlo ve formě kvartální sleziny a to ve třetím měsíci 
kvartálu (vyhneme se tím prázdninám) a to na jeho začátku (vyhneme se tím 
Vánocům). Např. první středa v měsíci (to je ten den, co houkají sirény, 
může to být hezká upomínka, kterou Vám ani Google nezorganizuje :o). Je 
jedno, zda se to vžije jen pro Brno, nebo se najdou i jiné lokality. 
Každopádně myslím, že by bylo fajn z každé sleziny udělat i nějaký stručný 
report, protože prakticky vždy tam padne něco podnětného.

4 setkání ročně nejsou až tak moc, ne? Letos bychom stihli ještě dvě a to 
7.9. a 7.12. ...

Předem díky za reakce

vop


__ _
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.
 org/listinfo/talk-cz

" 


__ _
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)

"


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


Re: [Talk-ca] Mapping exit numbers and destinations in Canada

2016-08-16 Thread Manohar Erikipati
Hi everyone,

Thank you Harald, James and Kevin for your replies. We currently
follow the proposed mapping methods in the Wiki [1] James had
mentioned. We have observed that there are name tags given for
junction nodes[2] in which destinations were given. Is this a
previously agreed tagging method to render destinations on nodes or is
there any particular reason the name tags were given to the junction
nodes? Is it okay if we delete these name tags on junction nodes now
that we are giving destination, destination:street tags to the  exit
ways?


Cheers,

Manohar



1. http://wiki.openstreetmap.org/wiki/Exit_Info
2. 
https://cloud.githubusercontent.com/assets/8921295/17693961/387f991c-63bf-11e6-9a77-988221f47c41.png




On Thu, Aug 11, 2016 at 6:23 PM, Kevin Farrugia 
wrote:

> Yes - recently bootprint, andrewpmk, and I have been changing and
> correcting the name tags to destination in Ontario along the 400-Series
> highways. If you see a ramp/link that is named, it's fine to change it over
> to destination or correct a problem you find with it.
>
> On Aug 11, 2016 8:38 AM, "Harald Kliems"  wrote:
>
>> Hi Manohar:
>> It is my understanding that including destinations in the name is an
>> artifact of people tagging for the renderer (and/or tagging destinations at
>> a time before there was an established tagging scheme). If you search
>> through the talk-ca archives, you should be able to find some discussions
>> on the topic.
>>  Harald.
>>
>> On Thu, Aug 11, 2016 at 7:25 AM Manohar Erikipati 
>> wrote:
>>
>>> Hello everyone!
>>>
>>> Turn restriction sprint was met with an amazing response! We loved
>>> working with you all on adding turn-restrictions in Canada. We appreciate
>>> the timely help and suggestions we got which helped us add correct
>>> restrictions and to also maintain the quality of data we were adding on to
>>> OpenStreetMap. We hope that this support will continue further, as we are
>>> embarking on mapping exit numbers and destinations in the same 5 cities of
>>> Canada.
>>>
>>> We have made an easier workflow [1] with tasking manager [2] for adding
>>> exit and destinations. We would like your assistance, participation and
>>> continued involvement in the project. We have captured the details of this
>>> task here [3].
>>>
>>> After a preliminary look into the already mapped exit numbers and
>>> destinations, we have these observations:
>>>
>>> - We noticed that `destination` (places, cities) and `destination:ref`
>>> (highways) tags are being added to the nodes of exits as `name` tags.
>>> - Few exit nodes have destinations given in the `ref` tag.
>>> - The `destination:street` (towards streets, avenues, boulevard, rue)
>>> tags were not being used.
>>>
>>> To begin with, we have one question: Destinations given in the name tag
>>> of nodes is not usual protocol for adding these tags. We want to make sure
>>> whether it is valid or if we could change these tags to the `destination`
>>> based tags accordingly. For more details, here's the complete breakdown
>>> [4]. To reach out to more audience, we have captured this in a OSM diary
>>> post [5]. We would like to hear from the community about the agreed method
>>> of mapping exit numbers and destinations to take this forward.
>>>
>>> 1. https://gist.github.com/manoharuss/3a1b4f640aaf2c052365fcb1ddb09beb
>>> 2. http://cfn-tasking-manager-staging-vpc-387856624.us-east-1.
>>> elb.amazonaws.com/project/20
>>> 3. https://github.com/mapbox/mapping/issues/220
>>> 4. https://gist.github.com/poornibadrinath/9333f1489732c32c3ffa
>>> dd58e3068b7e
>>> 5. https://www.openstreetmap.org/user/poornibadrinath/diary/39246
>>>
>>> Thank you!
>>>
>>> Cheers,
>>> Manohar Erikipati
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread Petr Vozdecký
mapa pokrytí signálem IMHO nepatří do OSM, protože se jedná o přiliš 
dynamickou informaci, navíc s nepříliš vypovídající informací. Co to je 
"pokrytí"? Je to izočára vyjadřující -40 dBm? Nebo -60 dBm? Ve kterém 
kmitočtovém pásmu? Bude vytvořena na základě měření (reálný stav k okamžiku 
měření), nebo jako teoretická hodnota (výpočet na základě ideálního stavu 
známých či předpokládaných hodnot a veličin)?

Ještě jednou - tato informace je natolik dynamická (řádově mnoho-
mnohonásobně dynamičtější, než běžně mapované prvky jako cesty, objekty...) 
a současně relativní ve vztahu k zobrazované informaci (co vlastně 
zobrazuje? viz otázka síly signálu a pásma + otázka citlivosti a selektivity
přijímače terminálu - tedy mobilu), že se může možná hodit jako externě 
renderovaná bitmapová vrstva, nicméně v nativních OSM datech by teoreticky 
mohly být pouze hodnoty pro její výpočet (lokace BTS+výška ANT+ziskANT+
RFvýkon+útlum vedení+azimut+elevace+horizontální_vyzařovací_úhelANT+
vertikální_vyzařovací_úhelANT+dynamická_data_útlumu_prostředí...), který 
(pseudoodborníci prominou) je nakonec ve výsledku jen snůškou teoretických 
hodnot použitých po patřičné účelové interpretaci pro marketing 
provozovatele služby. Mj. také proto, že (a pseudoodbornící opět prominou) 
skutečnost, že v daném místě je teoreticky signál vůbec neznamená, že se 
uživateli s konkrétním přístrojem (opět výkon, typ antény...) podaří 
sestavit hovor či "jen" dostat data. Ono pokrytí na downlinku je jedna věc, 
k mobilní komunikaci je potřeba i ten uplink...

No a ještě jeden argument - mapa pokrytí komerční službou není 
kartografickou informací - je to trochu podobné, jako "mapa pokrytí služeb 
rozvážky jídla společnosti XYZ"...

vop



-- Původní zpráva --
Od: Janda Martin 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 8. 2016 10:38:31
Předmět: Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

"Osobne bych zvolil o neco drazsi SW na vypocet signalu: "RadioLab verze 4" 
:-)

http://www.crcdata.cz/index.php/radiokomunikacni-sw/rada-rl4/radiolab-4/rl4-
site

Martin

PS Pro upresneni: Pracuji na vyvoji systemu RadioLab


- Original Message -
From: "Michal Poupa" 
To: "OpenStreetMap Czech Republic" 
Sent: Tuesday, August 16, 2016 9:54:48 AM
Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

Na počítání signálu byl šel použit sw Radiomobile (
http://www.cplus.org/rmw/english1.html )
ale moc nechápu k čemu by to na OSM bylo...

16. 8. 2016 v 9:24, Janda Martin :

> Dobry den,
> 
> pridavani BTS do OSM bych zatim nedelal. 
> *) v OSM chybi stale spousta domu a kominu na kterych jsou BTS umisteny. 
Cast dat je posunuta
> *) Na BTS stanovistich se meni parametry
> *) OSM data jsou spise staticka.
> 
> *) dle meho nazoru mapa pokyti signalem rozhodne nepatri do OSM.
> Navic bez parametru primo od operatoru/CTU nelze spocitat. Navic se jedna 
o relativne dynamickou zalezitost
> 
> --- spis bych navrhl zvysit kvalitu dat pro CR
> *) doplnit kominy
> *) jak to vypada s databazi stromu? (neco tu letos probehlo)
> *) je potreba zjistit aby nova data nebyla vkladana do OSM posunuta
> *) oprava starych silnich a ploch ktere jsou posunute az o desitky metru
> *) omezit rucni prekreslovani z leteckych fotek ktere nemaji kompenzovane 
zkresleni
> 
> --- pred editovanim detailu (zahradky, ploty, cesty, ...)
> 1) v oblasti importovat budovy RUIAN
> 2) importovat RUIAN lands
> 
> *) pak teprve dokreslit detailni objekty. Dost casto se stava ze detily 
jsou dokreslene posunute a velmi zjednodusene
> 
> Martin
> 
> - Original Message -
> From: "Pavel Machek" 
> To: "OpenStreetMap Czech Republic" 
> Sent: Monday, August 15, 2016 11:06:53 PM
> Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314
> 
> Ahoj!
> 
>> Mapováním BTSek se zabývají nadšenci na gsmweb.cz a jsou v tom hodně
>> dobří. Možná by s OSM rádi spolupracovali.
> 
> No, gsmweb ma docela kompletni a velmi presnou databazi, ktera by se
> urcite v openstreetmap vyjimala. Otazka je jestli ji daji, myslim ze
> pred par lety to vypadalo spis zaporne. Ale treba se situace
> zmenila...
> 
> Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/
blog.html
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

___
Talk-cz mailing list

Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-16 Thread Martin Koppenhoefer


sent from a phone

> Il giorno 16 ago 2016, alle ore 09:06, Vittorio Bertola  ha 
> scritto:
> 
> L'unica soluzione che non crea arbitrarietà, flame infiniti e accuse di 
> parzialità (o peggio dà potenzialmente spazio ad accuse politicizzate di 
> leghismo/separatismo/razzismo...) è quella di usare anche per i place i soli 
> nomi ufficiali, in italiano e basta


allora è messo davvero male l'Italia, se si vuole la forza della legge e del 
governo centrale per tenere insieme tutti i vari pezzi? Se fosse davvero così 
sarebbe solo questione del tempo finché volerebbe tutto a parte, non si riesce 
tenere insieme perenne con la forza cosa vuole separarsi ;-)


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


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-16 Thread Martin Koppenhoefer


sent from a phone

> Il giorno 16 ago 2016, alle ore 09:06, Vittorio Bertola  ha 
> scritto:
> 
> e perché non ho capito chi definisce quale sia la "comunità locale" che può 
> decidere quali lingue includere: gli utenti della Regione? del Comune? 
> dell'area etnica tradizionale, es. le vallate occitane?


la comunità locale sono le persone che vivono un luogo, che lo frequentano 
abitualmente e che lo conoscono. Non c'è bisogno di residenza o domicilio, ma 
c'è bisogno di una buona conoscenza diretta e attuale. Vivere nella stessa 
Regione non vuol dire necessariamente di essere locale in tutti i luoghi di 
quella Regione.


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


Re: [Talk-GB] Defibrillator Mapping

2016-08-16 Thread Robert Whittaker (OSM lists)
Just to let you know, that I've now got another dataset in my
Defibrillator comparison tool at http://robert.mathmos.net/osm/defib/
. East Midlands Ambulance Service has provided the locations of AEDs
that they know about, and these have now been imported into the tool.
As in other areas, our mapping of Defibrillators in the East Midlands
doesn't seem to be very complete yet...

Robert.

On 22 April 2016 at 14:43, Robert Whittaker (OSM lists)
 wrote:
> It was suggested that trying to increase our mapping of public
> Defibrillators would be a good think. After a bit of digging, it seems
> that Ambulance Services typically maintain a list of locations, with a
> view to informing people about them if a 999 call comes in nearby
> where one might be useful.
>
> The different services seem to take quite different views on these
> lists. My local service (East of England) actively publicise their
> list 
> (http://www.eastamb.nhs.uk/Get-involved/Community-Public-Access-Defibrillators.htm)
> on the grounds that raising awareness of the locations will make it
> more likely that someone will know about and find a defibrillator in
> an emergency. Other services have refused FOI requests on the (IMO
> spurious) grounds that publicising the list will make thefts /
> vandalism more likely, and out of date information may lead to people
> wasting time in an emergency.
>
> Anyway, I've taken the East of England list from
> http://www.eastamb.nhs.uk/Get%20involved/CPADs/CPAD%20List.pdf , and
> done a comparison with the OSM data. A rough and ready tool can be
> found at http://robert.mathmos.net/osm/defib/progress/ for any other
> locals who want to use it. We've got a small number of locations they
> haven't, and some of their postcodes may not be quite right. But there
> are a lot on their list that aren't mapped yet!
>
> Regarding tagging, it seems that a lot of the cabinets have a
> reference number on the outside, so I'd suggest recording that in the
> ref=* tag. Also, I think a description of the location would be useful
> (e.g. "Outside wall of McDonalds, facing Store 21") to help people
> find the defibrillator when they need it. I've been putting something
> like that in a location=* key.
>
> In terms of getting more data, I've put in FOI requests to the East
> and West Midlands Ambulance Services for starters, so we'll see what
> line they take...


-- 
Robert Whittaker

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


Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread Janda Martin
Osobne bych zvolil o neco drazsi SW na vypocet signalu: "RadioLab verze 4" :-)

http://www.crcdata.cz/index.php/radiokomunikacni-sw/rada-rl4/radiolab-4/rl4-site

  Martin

PS Pro upresneni: Pracuji na vyvoji systemu RadioLab


- Original Message -
From: "Michal Poupa" 
To: "OpenStreetMap Czech Republic" 
Sent: Tuesday, August 16, 2016 9:54:48 AM
Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re:  WeeklyOSM CZ 314

Na počítání signálu byl šel použit sw Radiomobile (
http://www.cplus.org/rmw/english1.html )
 ale moc nechápu k čemu by to na OSM bylo...

16. 8. 2016 v 9:24, Janda Martin :

> Dobry den,
> 
>  pridavani BTS do OSM bych zatim nedelal. 
> *) v OSM chybi stale spousta domu a kominu na kterych jsou BTS umisteny. Cast 
> dat je posunuta
> *) Na BTS stanovistich se meni parametry
> *) OSM data jsou spise staticka.
> 
> *) dle meho nazoru mapa pokyti signalem rozhodne nepatri do OSM.
>Navic bez parametru primo od operatoru/CTU nelze spocitat. Navic se jedna 
> o relativne dynamickou zalezitost
> 
> --- spis bych navrhl zvysit kvalitu dat pro CR
> *) doplnit kominy
> *) jak to vypada s databazi stromu? (neco tu letos probehlo)
> *) je potreba zjistit aby nova data nebyla vkladana do OSM posunuta
> *) oprava starych silnich a ploch ktere jsou posunute az o desitky metru
> *) omezit rucni prekreslovani z leteckych fotek ktere nemaji kompenzovane 
> zkresleni
> 
> --- pred editovanim detailu (zahradky, ploty, cesty, ...)
> 1) v oblasti importovat budovy RUIAN
> 2) importovat RUIAN lands
> 
> *) pak teprve dokreslit detailni objekty. Dost casto se stava ze detily jsou 
> dokreslene posunute a velmi zjednodusene
> 
>  Martin
> 
> - Original Message -
> From: "Pavel Machek" 
> To: "OpenStreetMap Czech Republic" 
> Sent: Monday, August 15, 2016 11:06:53 PM
> Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re:  WeeklyOSM CZ 314
> 
> Ahoj!
> 
>> Mapováním BTSek se zabývají nadšenci na gsmweb.cz a jsou v tom hodně
>> dobří. Možná by s OSM rádi spolupracovali.
> 
> No, gsmweb ma docela kompletni a velmi presnou databazi, ktera by se
> urcite v openstreetmap vyjimala. Otazka je jestli ji daji, myslim ze
> pred par lety to vypadalo spis zaporne. Ale treba se situace
> zmenila...
> 
>Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

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


Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread Jakub Sykora
Pokud neznáš vyzařovací diagramy, azimuty, elevace antén, výkony tak 
stejně nešlo. Respektive by z toho byl nějaký pavýsledek.


K

Dne 16.8.2016 v 09:54 Michal Poupa napsal(a):

Na počítání signálu byl šel použit sw Radiomobile (
http://www.cplus.org/rmw/english1.html )
 ale moc nechápu k čemu by to na OSM bylo...

16. 8. 2016 v 9:24, Janda Martin :


Dobry den,

 pridavani BTS do OSM bych zatim nedelal.
*) v OSM chybi stale spousta domu a kominu na kterych jsou BTS umisteny. Cast 
dat je posunuta
*) Na BTS stanovistich se meni parametry
*) OSM data jsou spise staticka.

*) dle meho nazoru mapa pokyti signalem rozhodne nepatri do OSM.
   Navic bez parametru primo od operatoru/CTU nelze spocitat. Navic se jedna o 
relativne dynamickou zalezitost

--- spis bych navrhl zvysit kvalitu dat pro CR
*) doplnit kominy
*) jak to vypada s databazi stromu? (neco tu letos probehlo)
*) je potreba zjistit aby nova data nebyla vkladana do OSM posunuta
*) oprava starych silnich a ploch ktere jsou posunute az o desitky metru
*) omezit rucni prekreslovani z leteckych fotek ktere nemaji kompenzovane 
zkresleni

--- pred editovanim detailu (zahradky, ploty, cesty, ...)
1) v oblasti importovat budovy RUIAN
2) importovat RUIAN lands

*) pak teprve dokreslit detailni objekty. Dost casto se stava ze detily jsou 
dokreslene posunute a velmi zjednodusene

 Martin

- Original Message -
From: "Pavel Machek" 
To: "OpenStreetMap Czech Republic" 
Sent: Monday, August 15, 2016 11:06:53 PM
Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re:  WeeklyOSM CZ 314

Ahoj!


Mapováním BTSek se zabývají nadšenci na gsmweb.cz a jsou v tom hodně
dobří. Možná by s OSM rádi spolupracovali.


No, gsmweb ma docela kompletni a velmi presnou databazi, ktera by se
urcite v openstreetmap vyjimala. Otazka je jestli ji daji, myslim ze
pred par lety to vypadalo spis zaporne. Ale treba se situace
zmenila...

   Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

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


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



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


Re: [Talk-cz] Zpracování vrstevnic pro mapy

2016-08-16 Thread Jakub Sykora

Ahoj,

záleží, odkud čerpáš SRTM data a zda jsou tam interpolované voidy. V 
surových datech toho dost chybí.
Také je dobré se do těch zdrojových dat podívat, jak to vypadá v těch 
oblastech, kde selhal převod na vrstevnice, vypadá.


Jedna z možností je SRTM v4 ze http://srtm.csi.cgiar.org/
Udělali tam hodně práce na kvalitě dat. Ale jsou to pouze 90m data (3 
vteřinová)


Pokud to chceš méně hranaté, můžeš zkusit jednovteřinová data, ale opět 
platí, že je potřeba v datech vyplnit voidy nějak rozumně, protože i tam 
nějaké jsou. Viz https://lta.cr.usgs.gov/SRTMVF a SRTM 1 Arc-Second 
Global a stahova tmožno přes http://earthexplorer.usgs.gov/


K

Dne 16.8.2016 v 09:37 Lukáš Karas napsal(a):

Ahoj, měl bych dotaz na lidi kolem projektu openstreetmap.cz:
Vrstevnice které jsou součástí map si zpracováváte sami, nebo stahujete
předpřipravené z nějaké služby?

Zkoušel jsem do svých mobilních map (postavených nad OSM Scout knihovnou)
přidat vrstevnice, použil jsem Srtm2Osm tool pro vytvoření vrstevnic z SRTMv2
dat od Nasa. Vše vypadalo vpořádku, dokud jsem nezkusil Alpy, kde jsem narazil
na tyto podivnosti:
http://www.karry.cz/files/ContourLines_bug.png

Na OSM wiki jsem se dočetl že SRTM data mají tento problém na místech kde byl
sníh :-( Chtěl jsem vyzkoušet použít novější data (SRTMv3), ale pro ten jsem
zatím nenašel funkční nástroj...

Když se podívám na openstreetmap.cz, třeba na vrstvu zimní sporty tak tento
problém se ve vrstevnicích nevyskytuje...

Poradíte prosím jaký zdroj a nástroje použít pro dokonalé vrstevnice?

Díky, Lukáš



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



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


[OSM-talk] DWG looking for Chinese translation help

2016-08-16 Thread Paul Norman
The OSM Foundation Data Working Group is looking for help with 
translating a couple of messages to Chinese. These messages are about 
data we're going to need to redact, so we want to make sure they understand.


If you can help, please contact d...@osmfoundation.org


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


Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread Michal Poupa
Na počítání signálu byl šel použit sw Radiomobile (
http://www.cplus.org/rmw/english1.html )
 ale moc nechápu k čemu by to na OSM bylo...

16. 8. 2016 v 9:24, Janda Martin :

> Dobry den,
> 
>  pridavani BTS do OSM bych zatim nedelal. 
> *) v OSM chybi stale spousta domu a kominu na kterych jsou BTS umisteny. Cast 
> dat je posunuta
> *) Na BTS stanovistich se meni parametry
> *) OSM data jsou spise staticka.
> 
> *) dle meho nazoru mapa pokyti signalem rozhodne nepatri do OSM.
>Navic bez parametru primo od operatoru/CTU nelze spocitat. Navic se jedna 
> o relativne dynamickou zalezitost
> 
> --- spis bych navrhl zvysit kvalitu dat pro CR
> *) doplnit kominy
> *) jak to vypada s databazi stromu? (neco tu letos probehlo)
> *) je potreba zjistit aby nova data nebyla vkladana do OSM posunuta
> *) oprava starych silnich a ploch ktere jsou posunute az o desitky metru
> *) omezit rucni prekreslovani z leteckych fotek ktere nemaji kompenzovane 
> zkresleni
> 
> --- pred editovanim detailu (zahradky, ploty, cesty, ...)
> 1) v oblasti importovat budovy RUIAN
> 2) importovat RUIAN lands
> 
> *) pak teprve dokreslit detailni objekty. Dost casto se stava ze detily jsou 
> dokreslene posunute a velmi zjednodusene
> 
>  Martin
> 
> - Original Message -
> From: "Pavel Machek" 
> To: "OpenStreetMap Czech Republic" 
> Sent: Monday, August 15, 2016 11:06:53 PM
> Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re:  WeeklyOSM CZ 314
> 
> Ahoj!
> 
>> Mapováním BTSek se zabývají nadšenci na gsmweb.cz a jsou v tom hodně
>> dobří. Možná by s OSM rádi spolupracovali.
> 
> No, gsmweb ma docela kompletni a velmi presnou databazi, ktera by se
> urcite v openstreetmap vyjimala. Otazka je jestli ji daji, myslim ze
> pred par lety to vypadalo spis zaporne. Ale treba se situace
> zmenila...
> 
>Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread lars lingner
Hallo Liste,

seit einigen Wochen wird an der IT hinter openstreetmap.de und
fossgis.de gearbeitet. Gestern erfolgte die Umstellung auf den neuen
Server. Der neue Server hat noch kein "richtiges" Zertifikat und Browser
zeigen daraufhin berechtigterweise eine Warnung an.

Es ist möglich im Browser eine Ausnahme zu konfigurieren. Dadurch kann
dann weiterhin auf die Webseite zugegriffen werden.

Die richtige Lösung ist aber auf dem Server ein gültiges Zertifikat zu
hinterlegen. Daran wird gearbeitet. Bitte habt noch einige Tage Geduld.
Manche Fehler fallen auch jetzt erst auf, da so einige "alte Zöpfe"
abgeschnitten wurden.

Bei weiteren Fragen oder gar Bedenken könnt ihr gerne hier auf der Liste
fragen.

Viele Grüße aus Berlin

Lars



Am 16.08.2016 um 08:06 schrieb goegeo:
> Hallo Liste. Seit gestern wird mir beim Abrufen der deutschen
> Openstreetmap-Homepage (https://www.openstreetmap.de) folgender
> Warnhinweis für eine mangelhafte Seitenkonfiguration dargestellt. Kann
> jemand von Euch mir, als einem Laien der EDV-Technik, weiterhelfen? Ich
> nutze Firefox 47 in der Dateiversion 47.0.0.5999 auf Windows 7 Home
> Premium (Service-Pack 1)
> 
> Beste Grüße, Nico
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Frederik Ramm
Hallo,

On 08/16/2016 08:06 AM, goegeo wrote:
> Hallo Liste. Seit gestern wird mir beim Abrufen der deutschen 
> Openstreetmap-Homepage (https://www.openstreetmap.de) folgender 
> Warnhinweis für eine mangelhafte Seitenkonfiguration dargestellt.

Die Seite wurde am Wochenende auf einen neuen Server umgezogen, das
Zertifikat kommt noch nach ;)

Bye
Frederik

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

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


[Talk-cz] Zpracování vrstevnic pro mapy

2016-08-16 Thread Lukáš Karas
Ahoj, měl bych dotaz na lidi kolem projektu openstreetmap.cz:
Vrstevnice které jsou součástí map si zpracováváte sami, nebo stahujete 
předpřipravené z nějaké služby? 

Zkoušel jsem do svých mobilních map (postavených nad OSM Scout knihovnou) 
přidat vrstevnice, použil jsem Srtm2Osm tool pro vytvoření vrstevnic z SRTMv2 
dat od Nasa. Vše vypadalo vpořádku, dokud jsem nezkusil Alpy, kde jsem narazil 
na tyto podivnosti:
http://www.karry.cz/files/ContourLines_bug.png

Na OSM wiki jsem se dočetl že SRTM data mají tento problém na místech kde byl 
sníh :-( Chtěl jsem vyzkoušet použít novější data (SRTMv3), ale pro ten jsem 
zatím nenašel funkční nástroj...

Když se podívám na openstreetmap.cz, třeba na vrstvu zimní sporty tak tento 
problém se ve vrstevnicích nevyskytuje...

Poradíte prosím jaký zdroj a nástroje použít pro dokonalé vrstevnice?

Díky, Lukáš



signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Carl von Einem

Hier sehe ich unter "Erweitert" noch:
www.openstreetmap.de verwendet ein ungültiges Sicherheitszertifikat. Das 
Zertifikat gilt nur für folgende Namen: www.fossgis.de, fossgis.de 
Fehlercode: SSL_ERROR_BAD_CERT_DOMAIN


Hihi, SSL_ERROR_BAD_CERT_DOMAIN schafft auch Adobe immer mal. Und bei 
Adobe finde ich das unprofessionell, bei osm .de komme ich damit 
zurecht, würde aber trotzdem eine andere Lösung wie cacert.org präferieren.


Um diese Fehlermeldung mal in einen gewissen Kontext zu rücken: eine 
https Verbindung mit so einer Fehlermeldung ist erst mal genauso sicher 
oder unsicher wie jede http (ohne 's') Seite. Man kann jetzt unter 
"Erweitert" eine "Ausnahme hinzufügen...", wenn man sich überlegt, ob 
das selbst signierte (also nicht bereits im Browser hinterlegte) 
Zertifikat bzw. dessen Aussteller vertrauenswürdig ist und vor allem: ob 
man sensible Daten überträgt. (Dagegen war nur als Beispiel der 
Webmailer-Login von GMX jahrelang per default unter einer http-Adresse 
erreichbar, das Passwort wurde somit im Klartext zwischen Client und 
Server übertragen...)


Insgesamt ein seit langer Zeit bestehendes Problem in der Nutzerführung 
von Browsern: komplett unsicher übertragende Seiten werden "normal" 
angezeigt; mit einem eigenen Zertifikat abgesicherte Seiten provozieren 
eigenartige Fehlermeldungen wie die hier berichtete; kommerzielle 
Zertifikats-Anbieter, die als Default im Browser hinterlegt sind und 
damit als scheinbar "vertrauenswürdig" angezeigt werden, können genau 
diese Sicherheit nicht unbedingt garantieren, es gibt da zahlreiche 
schwarze Schafe.


In dem Fall werde ich jetzt bei "Erweitert" -> "Ausnahme hinzufügen...", 
dort "Diese Ausnahme dauerhaft speichern" deaktivieren, mir das Zert 
ansehen, und mal gucken, was für ein Anbieter hier im Spiel ist. Dann 
"Sicherheits-Ausnahmeregel bestätigen" und openstreetmap.de besuchen. 
Was jetzt passiert: Angreifer könnten mit ansehen, welche Unterseiten 
ich auf der domain ansehe, einen login finde ich jetzt nicht. 
Kreditkartendaten muss man auch nicht unbedingt hier in ein Formular 
eintragen.


Hier steht jetzt auch "Der FOSSGIS e.V. betreibt diese Webseiten mit und 
für die Community." Also der Zertifikatsinhaber, über dessen Server das 
anscheinend gehostet wird, der aber die domain noch nicht in seinem 
Zertifikat eingetragen hat.


Hoffentlich war das jetzt nachvollziehbar und korrekt genug erklärt.

Schöne Grüsse,
Carl

Andreas Schmidt wrote on 16.08.16 08:32:

Hallo,

bei mir auch. (Firefox 48.0)

„Diese Verbindung ist nicht sicher
Der Inhaber von www.openstreetmap.de hat die Website nicht richtig
konfiguriert. Firefox hat keine Verbindung mit dieser Website aufgebaut,
um Ihre Informationen vor Diebstahl zu schützen.
Weitere Informationen…“

„www.openstreetmap.de uses an invalid security certificate. The
certificate is not trusted because it is self-signed. The certificate is
not valid for the name www.openstreetmap.de. Error code:
SEC_ERROR_UNKNOWN_ISSUER “

[Ausnahme hinzufügen] -Schaltfläche anklicken

Grüße
Andreas



Am 16.08.2016 um 08:06 schrieb goegeo:

Hallo Liste. Seit gestern wird mir beim Abrufen der deutschen
Openstreetmap-Homepage (https://www.openstreetmap.de) folgender
Warnhinweis für eine mangelhafte Seitenkonfiguration dargestellt. Kann
jemand von Euch mir, als einem Laien der EDV-Technik, weiterhelfen?
Ich nutze Firefox 47 in der Dateiversion 47.0.0.5999 auf Windows 7
Home Premium (Service-Pack 1)

Beste Grüße, Nico



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


Re: [Talk-cz] mapovani signalu vs. BTS was Re: WeeklyOSM CZ 314

2016-08-16 Thread Janda Martin
Dobry den,

  pridavani BTS do OSM bych zatim nedelal. 
*) v OSM chybi stale spousta domu a kominu na kterych jsou BTS umisteny. Cast 
dat je posunuta
*) Na BTS stanovistich se meni parametry
*) OSM data jsou spise staticka.

*) dle meho nazoru mapa pokyti signalem rozhodne nepatri do OSM.
Navic bez parametru primo od operatoru/CTU nelze spocitat. Navic se jedna o 
relativne dynamickou zalezitost

--- spis bych navrhl zvysit kvalitu dat pro CR
*) doplnit kominy
*) jak to vypada s databazi stromu? (neco tu letos probehlo)
*) je potreba zjistit aby nova data nebyla vkladana do OSM posunuta
*) oprava starych silnich a ploch ktere jsou posunute az o desitky metru
*) omezit rucni prekreslovani z leteckych fotek ktere nemaji kompenzovane 
zkresleni

--- pred editovanim detailu (zahradky, ploty, cesty, ...)
1) v oblasti importovat budovy RUIAN
2) importovat RUIAN lands

*) pak teprve dokreslit detailni objekty. Dost casto se stava ze detily jsou 
dokreslene posunute a velmi zjednodusene

  Martin

- Original Message -
From: "Pavel Machek" 
To: "OpenStreetMap Czech Republic" 
Sent: Monday, August 15, 2016 11:06:53 PM
Subject: Re: [Talk-cz] mapovani signalu vs. BTS was Re:  WeeklyOSM CZ 314

Ahoj!

> Mapováním BTSek se zabývají nadšenci na gsmweb.cz a jsou v tom hodně
>  dobří. Možná by s OSM rádi spolupracovali.

No, gsmweb ma docela kompletni a velmi presnou databazi, ktera by se
urcite v openstreetmap vyjimala. Otazka je jestli ji daji, myslim ze
pred par lety to vypadalo spis zaporne. Ale treba se situace
zmenila...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

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


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-16 Thread Vittorio Bertola

Il 10/08/16 19:39, Paolo Monegato ha scritto:

Vorrei aggiungere una piccola riflessione in tema di ufficialità della
toponomastica e filosofia di OSM.
Un tempo i cartografi incaricati dagli istituti preposti giravano per
mappare il paese e tra errori di comprensione e palesi invenzioni (in
stile Tolomei) hanno definito i nomi ufficiali. Era una cartografia che
veniva dall'alto.
OSM invece è una mappa costruita dal basso, ed è dalla strada che si
prendono i dati. Per quale motivo per quanto riguarda la toponomastica
si dovrebbe ignorare il territorio e prendere il dato dall'alto?


Scusa se reintervengo, ma allora non capisco proprio il senso della tua 
posizione. Una settimana fa mi hai detto che però secondo te il doppio 
nome si può mettere per il sardo ma non per il piemontese, perché solo 
la prima lingua è tutelata dalla legge 482/99... ma questa è esattamente 
una distinzione imposta dall'alto per regola nazionale, proprio come 
quella per cui il nome ufficiale è solo in italiano.


Se l'idea è che la mappa è "costruita dal basso", decisa dalla comunità 
e basata sul principio di riportare nel "name" qualsiasi toponimo usato 
comunemente sul territorio, allora tutte le lingue sono uguali e hanno 
diritto di vedere il proprio toponimo inserito in "name", purché siano 
ampiamente usate sul territorio e purché la comunità locale sia 
d'accordo. Solo che questa linea porta al caos, perché a quel punto le 
lingue non ufficiali effettivamente usate sul territorio sono molte (in 
molti Comuni anche piccoli ci sono comunità immigrate che sono ben più 
numerose dei parlanti della lingua locale tradizionale, ufficiale o meno 
che sia: su che base le vuoi discriminare?), e perché non ho capito chi 
definisce quale sia la "comunità locale" che può decidere quali lingue 
includere: gli utenti della Regione? del Comune? dell'area etnica 
tradizionale, es. le vallate occitane?


L'unica soluzione che non crea arbitrarietà, flame infiniti e accuse di 
parzialità (o peggio dà potenzialmente spazio ad accuse politicizzate di 
leghismo/separatismo/razzismo...) è quella di usare anche per i place i 
soli nomi ufficiali, in italiano e basta a parte la provincia di 
Bolzano, e comunque seguendo anche in futuro le deliberazioni in materia 
degli organi istituzionali competenti. Tutto il resto è più che 
benvenuto, ma va in name:*...


Ciao
--
vb.   Vittorio Bertola - vb [a] bertola.eu   <
>now blogging & more at http://bertola.eu/   <

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


Re: [Talk-cz] kvartální piva

2016-08-16 Thread Jan Martinec
Hmm, nejak to propadlo do hlubin mailboxu. Za mne super napad - obvykle
jsem v Praze a okoli.

Honza Piskvor Martinec

Dne 16. 8. 2016 8:08 dop. napsal uživatel "Ladislav Nesnera" <
nesn...@email.cz>:

> Myšlénku mám za dobrou, klíč za geniální (y) a reakce za překvapivě
> nulové.. :-OOO
>
>
>
> On 09/08/16 00:16, Petr Vozdecký wrote:
>
> ahoj,
>
> navazuji tímto na nějakou debatu dříve, myslím na SotMu...? což konec
> konců není ani důležité:
>
> diskutovali jsme potřebu zavést do regionálních setkání (čti: sleziny u
> piva) jakousi pravidelnost - ne snad z důvodů nutné pravidelnosti jako
> takové, ale spíše proto, abychom si ulehčili nekonečné potíže s hledáním
> ochotných svolavatelů a pak vhodných termínů a nakonec i ideálních míst...,
> prostě pravidelnost proto, aby ta setkání proběhla bez závislosti na
> malicherných okolnostech a současně i proto, aby je bylo možné lépe
> (dlouhodobě) ze strany účastníků plánovat.
>
> Tedy (po předchozí konzultaci s aktivními účastníky brněnských slezin)
> navrhuji zavést pravidlo ve formě kvartální sleziny a to ve třetím měsíci
> kvartálu (vyhneme se tím prázdninám) a to na jeho začátku (vyhneme se tím
> Vánocům). Např. první středa v měsíci (to je ten den, co houkají sirény,
> může to být hezká upomínka, kterou Vám ani Google nezorganizuje :o). Je
> jedno, zda se to vžije jen pro Brno, nebo se najdou i jiné lokality.
> Každopádně myslím, že by bylo fajn z každé sleziny udělat i nějaký stručný
> report, protože prakticky vždy tam padne něco podnětného.
>
> 4 setkání ročně nejsou až tak moc, ne? Letos bychom stihli ještě dvě a to
> 7.9. a 7.12. ...
>
> Předem díky za reakce
>
> vop
>
> ___
> Talk-cz mailing 
> listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [OSM-talk-be] dodentocht app

2016-08-16 Thread joost schouppe
I think it might have caused the Antwerp region to pop up in the Trending
Places of OSM tiles:

https://twitter.com/geometalab/status/764779545237094400

2016-08-15 10:25 GMT+02:00 Bart Vanherck :

> I just want to mention here that the organisation of Dodentocht used this
> year openstreetmap data for tracking purposes.
>
> https://webapp.dodentocht.be
>
> mvg,
>
> Bart
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup

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


Re: [Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread Andreas Schmidt
Hallo,

bei mir auch. (Firefox 48.0)

„Diese Verbindung ist nicht sicher
Der Inhaber von www.openstreetmap.de hat die Website nicht richtig
konfiguriert. Firefox hat keine Verbindung mit dieser Website aufgebaut,
um Ihre Informationen vor Diebstahl zu schützen.
Weitere Informationen…“

„www.openstreetmap.de uses an invalid security certificate. The
certificate is not trusted because it is self-signed. The certificate is
not valid for the name www.openstreetmap.de. Error code:
SEC_ERROR_UNKNOWN_ISSUER “

[Ausnahme hinzufügen] -Schaltfläche anklicken

Grüße
Andreas



Am 16.08.2016 um 08:06 schrieb goegeo:
> Hallo Liste. Seit gestern wird mir beim Abrufen der deutschen
> Openstreetmap-Homepage (https://www.openstreetmap.de) folgender
> Warnhinweis für eine mangelhafte Seitenkonfiguration dargestellt. Kann
> jemand von Euch mir, als einem Laien der EDV-Technik, weiterhelfen?
> Ich nutze Firefox 47 in der Dateiversion 47.0.0.5999 auf Windows 7
> Home Premium (Service-Pack 1)
>
> Beste Grüße, Nico
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de




signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-cz] kvartální piva

2016-08-16 Thread Zbyněk Datinský
Za ostravu a široké okolí se mnou počítejte. Jen bych tam nerad seděl u piva
sám :-)
datin



-- Původní zpráva --
Od: Ladislav Nesnera 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 8. 2016 8:08:25
Předmět: Re: [Talk-cz] kvartální piva

"

Myšlénku mám za dobrou, klíč za geniální (y) a reakce za překvapivě nulové..
:-OOO





On 09/08/16 00:16, Petr Vozdecký wrote:

"ahoj,

navazuji tímto na nějakou debatu dříve, myslím na SotMu...? což konec konců 
není ani důležité:

diskutovali jsme potřebu zavést do regionálních setkání (čti: sleziny u 
piva) jakousi pravidelnost - ne snad z důvodů nutné pravidelnosti jako 
takové, ale spíše proto, abychom si ulehčili nekonečné potíže s hledáním 
ochotných svolavatelů a pak vhodných termínů a nakonec i ideálních míst..., 
prostě pravidelnost proto, aby ta setkání proběhla bez závislosti na 
malicherných okolnostech a současně i proto, aby je bylo možné lépe 
(dlouhodobě) ze strany účastníků plánovat.

Tedy (po předchozí konzultaci s aktivními účastníky brněnských slezin) 
navrhuji zavést pravidlo ve formě kvartální sleziny a to ve třetím měsíci 
kvartálu (vyhneme se tím prázdninám) a to na jeho začátku (vyhneme se tím 
Vánocům). Např. první středa v měsíci (to je ten den, co houkají sirény, 
může to být hezká upomínka, kterou Vám ani Google nezorganizuje :o). Je 
jedno, zda se to vžije jen pro Brno, nebo se najdou i jiné lokality. 
Každopádně myslím, že by bylo fajn z každé sleziny udělat i nějaký stručný 
report, protože prakticky vždy tam padne něco podnětného.

4 setkání ročně nejsou až tak moc, ne? Letos bychom stihli ještě dvě a to 
7.9. a 7.12. ...

Předem díky za reakce

vop


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

" 

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

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


Re: [Talk-cz] kvartální piva

2016-08-16 Thread Ladislav Nesnera
Myšlénku mám za dobrou, klíč za geniální (y) a reakce za překvapivě
nulové.. :-OOO



On 09/08/16 00:16, Petr Vozdecký wrote:
> ahoj,
>
> navazuji tímto na nějakou debatu dříve, myslím na SotMu...? což konec
> konců není ani důležité:
>
> diskutovali jsme potřebu zavést do regionálních setkání (čti: sleziny
> u piva) jakousi pravidelnost - ne snad z důvodů nutné pravidelnosti
> jako takové, ale spíše proto, abychom si ulehčili nekonečné potíže s
> hledáním ochotných svolavatelů a pak vhodných termínů a nakonec i
> ideálních míst..., prostě pravidelnost proto, aby ta setkání proběhla
> bez závislosti na malicherných okolnostech a současně i proto, aby je
> bylo možné lépe (dlouhodobě) ze strany účastníků plánovat.
>
> Tedy (po předchozí konzultaci s aktivními účastníky brněnských slezin)
> navrhuji zavést pravidlo ve formě kvartální sleziny a to ve třetím
> měsíci kvartálu (vyhneme se tím prázdninám) a to na jeho začátku
> (vyhneme se tím Vánocům). Např. první středa v měsíci (to je ten den,
> co houkají sirény, může to být hezká upomínka, kterou Vám ani Google
> nezorganizuje :o). Je jedno, zda se to vžije jen pro Brno, nebo se
> najdou i jiné lokality. Každopádně myslím, že by bylo fajn z každé
> sleziny udělat i nějaký stručný report, protože prakticky vždy tam
> padne něco podnětného.
>
> 4 setkání ročně nejsou až tak moc, ne? Letos bychom stihli ještě dvě a
> to 7.9. a 7.12. ...
>
> Předem díky za reakce
>
> vop
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


[Talk-de] Deutsche Homepage - Fehlermeldung

2016-08-16 Thread goegeo
Hallo Liste. Seit gestern wird mir beim Abrufen der deutschen 
Openstreetmap-Homepage (https://www.openstreetmap.de) folgender 
Warnhinweis für eine mangelhafte Seitenkonfiguration dargestellt. Kann 
jemand von Euch mir, als einem Laien der EDV-Technik, weiterhelfen? Ich 
nutze Firefox 47 in der Dateiversion 47.0.0.5999 auf Windows 7 Home 
Premium (Service-Pack 1)


Beste Grüße, Nico

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