Re: [Talk-in] Boundary tagging scheme for India

[Naveen Francis]

This will give you an idea
http://www.kslublris.com/LRIS/Kerala/district.php
Just select Trissur or Ernakulum

--
naveenpf


On 23 March 2016 at 09:20, Jaisen Nedumpala  wrote:

>
>
> 2016-03-23 9:05 GMT+05:30 Jaisen Nedumpala :
>
>>
>>
>> 2016-03-22 22:46 GMT+05:30 Arun Ganesh :
>>
>>> My feedback on the current state of the proposal:
>>>
>>> # Admin Boundaries
>>>
>>> This looks good overall. The important aspect about admin boundaries is
>>> that they are fairly static and do not change unless through legislation.
>>> Is this understanding correct?
>>>
>>
>> Yes. Through legislation or through government notification. Changes in
>> Cadastral boundaries / Revenue village boundaries are usually done through
>> government notification.
>>
>>
>>>
>>> I would correct the admin_level values to closely match the same values
>>> used for countries around the world[1]. 2=national, 4=state, 6=district,
>>> 8=sub district, 10=revenue village (The odd numbers used for any groupings
>>> in between)
>>>
>>> # Political Boundaries
>>>
>>> Boundaries defined by the election commission and redrawn after each
>>> census by the Delimitation Commission [2]. The list currently covers the
>>> parliament and assembly constituencies, but no boundaries for local bodies.
>>>
>>
>> These are the boundaries defined by the Election Commission of India and
>> Delimitation Commission of India. Usually the boundaries of Legislative
>> Assembly Constituencies are defined as the grouping of Local Self
>> Government Institutions.
>>
>>
>>>
>>> These boundaries do not coincide with administrative boundaries, except
>>> maybe at the state level (admin_level=4)
>>>
>>
>> Boundaries of Legislative Aassembly Constituencies are defined as the
>> grouping of Local authorities like village panchayats, and municipalities,
>> but in the areas of larger local authorities like Municipal Corporations,
>> those are defined as a grouping of Corporation Wards.
>>
>> See:
>>
>> http://www.ceo.kerala.gov.in/pdf/03-DELIMITATION/01-FO-KERALA.pdf
>>
>> Legislative Assembly Constituency is defined as, that one will fit within
>> the boundaries of a revenue district. A revenue district will include
>> several such Legislative Assembly Constituencies. The Parliament
>> Constituency is defined as a grouping of Legislative Assembly
>> Constituencies and which may span through more than one revenue district.
>>
>> See:
>>
>> http://www.ceo.kerala.gov.in/pdf/03-DELIMITATION/03-DELIMITED-LAC.pdf
>> http://www.ceo.kerala.gov.in/pdf/03-DELIMITATION/02-DELIMITED-HPC.pdf
>>
>>
>>>
>>> # Self governance boundaries
>>>
>>> These are technically political boundaries for self governance,
>>> according to the Panchayati Raj system[3] and Municapal bodies.
>>>
>>
>> The boundaries of Local Self Government Institutions are defined by STATE
>> Election Commissions, and Delimitation commissions of each State.
>>
>> See:
>> http://sec.kerala.gov.in/
>> http://delimitation.lsgkerala.gov.in/
>>
>>
>>>
>>> This is currently divided into rural and urban boundaries, but can
>>> probably be conflated together.
>>>
>>
>> Can be bifurcated too.
>>
>>
>>> It might also make sense to use a political_division value that matches
>>> the admin boundaries:
>>>
>>> Rural:
>>> 6=district/zilla panchayat, 8=block/subdistrict/mandal panchayat,
>>> 10=village/gram panchayat, 11=neighbourhood/ward gram sabha
>>>
>>>
>> Neighbourhood is a smaller entity than ward/gram sabha in Kerala.
>> Approximately 20-50 numbers of neighbourhoods will be there in Ward / gram
>> sabha.
>>
>
> Also, District Panchayats and Block Panchayats have their own Constituency
> Divisions. The Members of District panchayats, and Members of Block
> Panchayats are elected form those constituency divisions. Divisions of
> Block panchayats are defined as a grouping of Village Panchayat wards and,
> Divisions of District Panchayats are defined as a grouping of Block
> Panchayat wards.
>
>
>>
>>
>>> Urban:
>>> 6=city/town municipal body, 8=sub city/municipal zones,
>>> 10=suburb/municipal ward, 11=neighborhood/colony mohalla
>>>
>>
>> Also, The cantonment area are governed by cantonment boards, those areas
>> doesn't come within the rural / urban local bodies.
>>
>>
>>>
>>> Jaisen, would be great to hear your feedback on this.
>>>
>>>
>>> [1]
>>> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
>>> [2] http://eci.nic.in/delim/Acts/acts.asp
>>> [3] http://www.panchayat.gov.in/ebook/
>>> [4] https://en.wikipedia.org/wiki/Municipal_governance_in_India
>>>
>>>
>>> On Tue, Mar 22, 2016 at 9:31 PM, Arun Ganesh 
>>> wrote:
>>>
 Merging recent discussions from district[1] and constituency [2]
 boundaries.

 The current tagging scheme for boundaries in India[3]  has limitations
 since it was not effectively researched to properly separate revenue and
 local body 

Re: [Talk-in] Boundary tagging scheme for India

[Jaisen Nedumpala]

2016-03-22 22:46 GMT+05:30 Arun Ganesh :

> My feedback on the current state of the proposal:
>
> # Admin Boundaries
>
> This looks good overall. The important aspect about admin boundaries is
> that they are fairly static and do not change unless through legislation.
> Is this understanding correct?
>

Yes. Through legislation or through government notification. Changes in
Cadastral boundaries / Revenue village boundaries are usually done through
government notification.


>
> I would correct the admin_level values to closely match the same values
> used for countries around the world[1]. 2=national, 4=state, 6=district,
> 8=sub district, 10=revenue village (The odd numbers used for any groupings
> in between)
>
> # Political Boundaries
>
> Boundaries defined by the election commission and redrawn after each
> census by the Delimitation Commission [2]. The list currently covers the
> parliament and assembly constituencies, but no boundaries for local bodies.
>

These are the boundaries defined by the Election Commission of India and
Delimitation Commission of India. Usually the boundaries of Legislative
Assembly Constituencies are defined as the grouping of Local Self
Government Institutions.


>
> These boundaries do not coincide with administrative boundaries, except
> maybe at the state level (admin_level=4)
>

Boundaries of Legislative Aassembly Constituencies are defined as the
grouping of Local authorities like village panchayats, and municipalities,
but in the areas of larger local authorities like Municipal Corporations,
those are defined as a grouping of Corporation Wards.

See:

http://www.ceo.kerala.gov.in/pdf/03-DELIMITATION/01-FO-KERALA.pdf

Legislative Assembly Constituency is defined as, that one will fit within
the boundaries of a revenue district. A revenue district will include
several such Legislative Assembly Constituencies. The Parliament
Constituency is defined as a grouping of Legislative Assembly
Constituencies and which may span through more than one revenue district.

See:

http://www.ceo.kerala.gov.in/pdf/03-DELIMITATION/03-DELIMITED-LAC.pdf
http://www.ceo.kerala.gov.in/pdf/03-DELIMITATION/02-DELIMITED-HPC.pdf


>
> # Self governance boundaries
>
> These are technically political boundaries for self governance, according
> to the Panchayati Raj system[3] and Municapal bodies.
>

The boundaries of Local Self Government Institutions are defined by STATE
Election Commissions, and Delimitation commissions of each State.

See:
http://sec.kerala.gov.in/
http://delimitation.lsgkerala.gov.in/


>
> This is currently divided into rural and urban boundaries, but can
> probably be conflated together.
>

Can be bifurcated too.


> It might also make sense to use a political_division value that matches
> the admin boundaries:
>
> Rural:
> 6=district/zilla panchayat, 8=block/subdistrict/mandal panchayat,
> 10=village/gram panchayat, 11=neighbourhood/ward gram sabha
>
>
Neighbourhood is a smaller entity than ward/gram sabha in Kerala.
Approximately 20-50 numbers of neighbourhoods will be there in Ward / gram
sabha.


> Urban:
> 6=city/town municipal body, 8=sub city/municipal zones,
> 10=suburb/municipal ward, 11=neighborhood/colony mohalla
>

Also, The cantonment area are governed by cantonment boards, those areas
doesn't come within the rural / urban local bodies.


>
> Jaisen, would be great to hear your feedback on this.
>
>
> [1]
> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
> [2] http://eci.nic.in/delim/Acts/acts.asp
> [3] http://www.panchayat.gov.in/ebook/
> [4] https://en.wikipedia.org/wiki/Municipal_governance_in_India
>
>
> On Tue, Mar 22, 2016 at 9:31 PM, Arun Ganesh 
> wrote:
>
>> Merging recent discussions from district[1] and constituency [2]
>> boundaries.
>>
>> The current tagging scheme for boundaries in India[3]  has limitations
>> since it was not effectively researched to properly separate revenue and
>> local body boundaries.
>>
>> This is the reason to draw up a more well researched proposal[4]
>>
>> Jaisen, who has experience working with the panchayat office in Kerala
>> has just made the proposal more comprehensive[5]. This is right now the
>> most detailed description of various boundaries in India that one can find
>> anywhere online.
>>
>> This is a great time to get more eyes on this and work towards a final
>> scheme.
>>
>>
>> [1]
>> https://lists.openstreetmap.org/pipermail/talk-in/2016-March/002529.html
>> [2]
>> https://lists.openstreetmap.org/pipermail/talk-in/2016-March/002533.html
>>
>> [3]
>> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
>> [4] http://wiki.openstreetmap.org/wiki/WikiProject_India/Boundaries
>> [5]
>> http://wiki.openstreetmap.org/w/index.php?title=WikiProject_India/Boundaries=next=1280759
>>
>> --
>> Arun Ganesh
>> @planemad
>> 
>>
>
>
>
> 

[OSM-talk] DB Performance (was: JOSM plugin to import GeoJSON?_

[Mike Thompson]

This from the ogr2ogr documentation[1] may be relevant:

"When writing into transactional DBMS (SQLite/PostgreSQL,MySQL, etc...), it
might be beneficial to increase the number of INSERT statements executed
between BEGIN TRANSACTION and COMMIT TRANSACTION statements. This number is
specified with the -gt option. For example, for SQLite, explicitly
defining *-gt
65536* ensures optimal performance"

Mike
[1] http://www.gdal.org/ogr2ogr.html


On Tue, Mar 22, 2016 at 5:01 PM, Stefan Keller  wrote:

> Hi Frederik and Jukka
>
> Before I try give answers to performance let's be aware that we're (at
> least I am) speaking about a "desktop exchange format", not a storage
> fomat for GIS processing.
>
> But Frederik's comment piqued my curiosity and I did some quick comparison.
> I generated 1 mio. records in PostsGIS with this table
> CREATE TABLE benchmark (id serial primary key, txt varchar(32), geom
> geometry(point,4326) );
>
> Then I used OGR2OGR to create the following three file formats:
> GeoPackage (using 73.9 MB disk space), Shapefiles (dbf/shp/shx 117 MB)
> and Spatialite (173 MB).
>
> Creation time of GeoPackage was 18 sec., Shapefile 21 sec. and
> Spatialite 1 min 51 sec.
> So, GeoPackage is a bit faster than Shapefiles and significantly
> (about 37%) smaller in size.
> Spatialite in fact consumes much more disk space than Shapefile and
> GeoPackage, and Spatialite is several times slower for creation time.
>
> This could explain the preformance issues of Spatialite Frederic mentioned.
>
> :Stefan
>
> 2016-03-22 13:56 GMT+01:00 Jukka Rahkonen :
> > Frederik Ramm  remote.org> writes:
> >
> >>
> >> Hi,
> >>
> >> On 03/20/2016 10:56 PM, Stefan Keller wrote:
> >> > But Shapefile remains an oldtimer with more drawbacks than limited
> >> > field names; see [1].
> >> > GeoJSON (ascii) and GeoPackages (binary) are formats which are more
> >> > suited for the job.
> >> > I still have hope that JOSM will be able to read those vector formats
> too.
> >>
> >> Frankly, whenever I venture into the brave new world of Spatialite, I
> >> come back to good old shape files after a while for performance reasons.
> >> I'm not sure if Geopackage has significant performance improvements over
> >> simple Spatialite but if it hasn't then my recommendation for simple GIS
> >> processing is certainly to stick with shape files for the time being -
> >> despite all their shortcomings.
> >
> >
> > Hi Frederic,
> >
> > I would like to receive some sample data, exact way to reproduce some of
> > your ventures and cold numbers about the speed you have experienced.
> > Spatialite does have it's limits but for plain selects with spatial and
> > attribute filters it can well outperform both shapefiles and PostGIS.
> >
> > I keep most vector data for WMS services in Spatialite or GeoPackage due
> to
> > the already mentioned and some other reasons:
> > - supports long attribute names
> > - supports strings longer than 255 characters
> > - supports SQL
> > - supports attribute indexes
> > - much less encoding problems due to UTF-8
> > - one single file vs. a bunch of files in shapefile, perhaps even split
> to
> > separate bunches for points, lines and polygons.
> >
> > For me SpatiaLite is a little bit slower than shapefiles if only spatial
> > filter (BBOX) is used but usually faster if also attribute filters are
> > involved, especially if more than one field is needed in filters
> (Shapefiles
> > can be sorted by one attribute only). Of course spatialite must have
> indexes
> > which suit the queries and when it comes to spatial index, the client
> must
> > know how to utilize the table based R-Tree index. I also recommend to
> VACUUM
> > once the database is ready to use.
> >
> > Many spatial operations are relatively slow in Spatialite and I don't
> > usually utilize them on-the-fly with WMS server. Instead, I run the
> > algorithm once and store the result into a new table because a few
> > mega/gigabytes of additional disk space is not crucial on the server.
> > However, such operations tend to be slow also if shapefiles are used as
> > source data.
> >
> > Write performance especially with concurrent writes is another story. I
> am
> > talking about read-only operations. I know that I am writing empty words
> as
> > far as I do not include reproducible facts but I am willing to join to a
> > controlled test if someone is organizing such.
> >
> > -Jukka Rahkonen-
> >
> >
> >
> >
> > ___
> > 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSRM-talk] hsgr error after many requests

[Steven M. Ottens]

Hi Daniel,

I was using the development branch of osrm-backend and the standard (eg 
npm install osrm) version of node-osrm. Since I couldn't figure out how 
to get the correct version of node-osrm installed on the remote machine 
I redid the entire process with the master branch.


It works now, thanks for the help,

Steven

On 3/19/2016 5:14 AM, Daniel Hofmann wrote:
Hm that sounds strange to me, too. What you're seeing is a failure in 
matching the first couple of bytes (which represents a fingerprint).


When you say

> I find this weird since I have done the entire set before (with a 
less elegant approach, but with the same *.osrm* files)


could it be that you ran osrm-extract / osrm-prepare (in develop 
branch now named osrm-contract) on .pbf files while on osrm-backend 
version N.
And now you updated osrm-backend to version N+x but you're still 
feeding it the old .osrm files? This is so far the only way I can see 
this happening.


Can you try reproducing the issue by running the toolchain on your 
.pbf extract.

That is put away the .osrm files for a moment and generate fresh ones.
Then run osrm-routed / node-osrm.

Cheers,
Daniel J H

On Fri, Mar 18, 2016 at 10:14 PM, Steven M. Ottens > wrote:


Hi all,

I'm busy trying to build a program that, given a road network, a
series of villages and a series of POIs will calculate the time to
the nearest POI for each village. There are 215000 villages and
85000 POIs, so I split the region in smaller squares to speed up
the process, I end up with 500 squares and for each square I get
the villages within the square and the POIs within a buffer around
the square. I run these two through osrm.table to get the time to
the nearest POI.

This works fine and my server slowly chugs along until at some
point (after 15 minutes and a hundred+ squares) I get this error:

TypeError: hsgr input file misses magic number. Check or reprocess
the file

I find this weird since I have done the entire set before (with a
less elegant approach, but with the same *.osrm* files) and why
does this error only show up after a while.

If anyone has any insights I'd be much obliged,

Steven

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




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


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

Re: [Talk-it] OSMAnd Live

[mircozorzo]

Questa di dare i soldi alla fondazione mi sembra una buona idea.

Ciao, Mirco



--
View this message in context: 
http://gis.19327.n5.nabble.com/OSMAnd-Live-tp5870406p5870460.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk] JOSM plugin to import GeoJSON?

[Stefan Keller]

Hi Frederik and Jukka

Before I try give answers to performance let's be aware that we're (at
least I am) speaking about a "desktop exchange format", not a storage
fomat for GIS processing.

But Frederik's comment piqued my curiosity and I did some quick comparison.
I generated 1 mio. records in PostsGIS with this table
CREATE TABLE benchmark (id serial primary key, txt varchar(32), geom
geometry(point,4326) );

Then I used OGR2OGR to create the following three file formats:
GeoPackage (using 73.9 MB disk space), Shapefiles (dbf/shp/shx 117 MB)
and Spatialite (173 MB).

Creation time of GeoPackage was 18 sec., Shapefile 21 sec. and
Spatialite 1 min 51 sec.
So, GeoPackage is a bit faster than Shapefiles and significantly
(about 37%) smaller in size.
Spatialite in fact consumes much more disk space than Shapefile and
GeoPackage, and Spatialite is several times slower for creation time.

This could explain the preformance issues of Spatialite Frederic mentioned.

:Stefan

2016-03-22 13:56 GMT+01:00 Jukka Rahkonen :
> Frederik Ramm  remote.org> writes:
>
>>
>> Hi,
>>
>> On 03/20/2016 10:56 PM, Stefan Keller wrote:
>> > But Shapefile remains an oldtimer with more drawbacks than limited
>> > field names; see [1].
>> > GeoJSON (ascii) and GeoPackages (binary) are formats which are more
>> > suited for the job.
>> > I still have hope that JOSM will be able to read those vector formats too.
>>
>> Frankly, whenever I venture into the brave new world of Spatialite, I
>> come back to good old shape files after a while for performance reasons.
>> I'm not sure if Geopackage has significant performance improvements over
>> simple Spatialite but if it hasn't then my recommendation for simple GIS
>> processing is certainly to stick with shape files for the time being -
>> despite all their shortcomings.
>
>
> Hi Frederic,
>
> I would like to receive some sample data, exact way to reproduce some of
> your ventures and cold numbers about the speed you have experienced.
> Spatialite does have it's limits but for plain selects with spatial and
> attribute filters it can well outperform both shapefiles and PostGIS.
>
> I keep most vector data for WMS services in Spatialite or GeoPackage due to
> the already mentioned and some other reasons:
> - supports long attribute names
> - supports strings longer than 255 characters
> - supports SQL
> - supports attribute indexes
> - much less encoding problems due to UTF-8
> - one single file vs. a bunch of files in shapefile, perhaps even split to
> separate bunches for points, lines and polygons.
>
> For me SpatiaLite is a little bit slower than shapefiles if only spatial
> filter (BBOX) is used but usually faster if also attribute filters are
> involved, especially if more than one field is needed in filters (Shapefiles
> can be sorted by one attribute only). Of course spatialite must have indexes
> which suit the queries and when it comes to spatial index, the client must
> know how to utilize the table based R-Tree index. I also recommend to VACUUM
> once the database is ready to use.
>
> Many spatial operations are relatively slow in Spatialite and I don't
> usually utilize them on-the-fly with WMS server. Instead, I run the
> algorithm once and store the result into a new table because a few
> mega/gigabytes of additional disk space is not crucial on the server.
> However, such operations tend to be slow also if shapefiles are used as
> source data.
>
> Write performance especially with concurrent writes is another story. I am
> talking about read-only operations. I know that I am writing empty words as
> far as I do not include reproducible facts but I am willing to join to a
> controlled test if someone is organizing such.
>
> -Jukka Rahkonen-
>
>
>
>
> ___
> 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] [BOT] [RFC]: water surfaces

[Warin]

On 23/03/2016 2:47 AM, Pierre Béland wrote:

On 2016-03-22 14:10, Frank Villaro-Dixon wrote:


># First goal:
>First goal is quite simple. The idea is to work only on relations
>which have a natural=water .  Then, it will:
>* Delete natural=water from all the ways if they are NOT closed or
>ring 0.
>

This is a good proposition to look at unclosed polygons and see if a 
potential incorrect keys to fix.


I agree with others that using a Bot is not a safe way to handle these 
problems. Could a script to extract such unclosed polygons be 
proposed?  This way, each local community could take care to fix data 
for their area, importing and examining the data in the JOSM Editor. 
The Todo plugin could be used to go through the items to correct.


Pierre



An unclosed polygon is an error ... and should be fixed.
These can be detected using OSM Inspector. There are lots of them!

Surely that is a higher priority than deleting duplicate tags from ways 
that exist in relations (closed of not)?
So go fix the unclosed polygons, that will have much more benefit to the 
map than the deletion of duplicates.



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

Re: [Talk-GB] [UK Chapter] Definition of OSM.

[Brian Prangle]

Echoing Jerry's  previous plea - please comment on the Google docs AoA-
there has been a fresh definition of OpenStreetMap there for several days

Regards
Brian

On 22 March 2016 at 21:32, Tim Waters  wrote:

> Frederik is correct in saying that OpenStreetMap Project does not
> appear in the OSMF Articles of Association.
>
> However, on the OSMF website, the following words are used: "The
> Foundation supports the OpenStreetMap Project."
>
> So the wider OSM "thing" is the OpenStreetMap Project rather than the
> OpenStreetMap Community. I quite like that differentiation, even
> though I cannot find the definition of what the project is!
>
> "supports" is also a quite different meaning than "managed by"
>
> If we wanted to have a definition that includes the OSMF: "The
> OpenStreetMap Project as currently supported by the OpenStreetMap
> Foundation Ltd" perhaps?
>
> Tim
>
> ___
> 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-cz] Galerie predevsim ceskych prikladu vyuziti OSM a vyzva k zaslani/oznameni dalsich prikladu vyuziti OSM

[Petr Vozdecký]

...že mě to nenapadlo, já marně hledal v DB OSM vč. historie editací, kde to
ten rendeRRRer vzal... :o)

Kakrrraholte!

vop



-- Původní zpráva --
Od: Jan Dudík 
Komu: OpenStreetMap Czech Republic 
Datum: 22. 3. 2016 23:07:44
Předmět: Re: [Talk-cz] Galerie predevsim ceskych prikladu vyuziti OSM a 
vyzva k zaslani/oznameni dalsich prikladu vyuziti OSM

"

Ad pirrráti:
je tam i Karrrlštejn, Starrrá Huť, Parrrdubice, Starrré Purrrkartice, 
Jarrrošov nad Nežárkou, Pernarrrec.





---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195



Dne 22. března 2016 21:37 Pavel Bokr  napsal(a):
" 



Ahoj,

 
 
diky za tipy, doplnil jsem do galerie:

- seznam.cz(http://seznam.cz) (zaklad, turistickou, zimni a zemepisnou)

- odkaz na tripomatic (zatim pracovne tam kde je) az tam toho bude vic tak 
bych tyhle on-line sluzby oddelil asi od dalsich vyuziti

- originalni PFko (zatim jako obrazek, “zivy” link bych uvital trvaly – jiz 
se resi, uvidime zda se vyresi)

 
 
+ jsem pridal ukazky stylu pirates (je tam i ten Karrrlin :-) a pencil, 
odkaz na parkovani v Praze

 
 
http://openstreetmap.cz/galerie(http://openstreetmap.cz/galerie)

 
 
 
 
kazde dalsi pripominky jakoz tipy vitany, kdyz sam na neco narazim tak taky 
pridam (urcite jsem za celou tu dobu taky neco videl, ale takto nasilim me 
najednou nic nenapadne, ale casem urcite jo).

 
 
 
 
Pavel Bokr

 
 
 
 


 
 

From: Pavel Zbytovský(mailto:zbytov...@gmail.com) 

Sent: Monday, March 21, 2016 9:34 AM

To: OpenStreetMap Czech Republic(mailto:talk-cz@openstreetmap.org) 

Subject: Re: [Talk-cz] Galerie predevsim ceskych prikladu vyuziti OSM a 
vyzva k zaslani/oznameni dalsich prikladu vyuziti OSM



 

 



Tak je hezké to ilustrovat na čr území, ale může být i jinde.. Třeba 
OpenSeaMap bych v čr neprezentoval :))) 
 
 
btw, ten pirátský styl normálně nabízí mapbox - tady mám stránku se všemi 
base-mapami mapboxu: http://zby.cz/parkovani(http://zby.cz/parkovani)

 
 
P.



 
 

On Mon, Mar 21, 2016 at 8:28 AM Michal Grézl  wrote:

"co takhle seznam pouzivajici osm mimo cr. to je asi nejdulezitejsi
pouziti osm v republice:)

2016-03-21 1:18 GMT+01:00 Pavel Bokr :
> Ahoj,
>
> ve spolupraci s Pavlem Zbytovskym jsem na osmap.cz(http://osmap.cz) 
vytvoril samostatnou
> galerii vyuziti OSM:
> http://openstreetmap.cz/galerie(http://openstreetmap.cz/galerie)
>
> Smyslem je ukazat vyuziti OSM predevsim v ceskych projektech a ceske
> komunite. Zatim je to takovy zarodek, verime ze dalsi priklady budou
> pribyvat a stanou se dalsi inspiraci jakymi ruznymi zpusoby lze OSM
> vyuzivat.
>
> Na konci je teda zminka i globalnich projektech nad daty OSM, aby se 
ukazalo
> alespon to nejzajimavejsi ze zahranicnich projektu (idealne nad CR). Z 
toho
> zahranici by tam asi mel byt jen vyber toho opravdu nejzajimavejsiho, aby
> bylo videt ze jake zajimave veci z toho delaji v zahranici a ze uzemi CR 
se
> neresi jen v ceskych projektech. Hlavni obsah teto stranky by vsak podle 
me
> melo byt ceske vyuziti.
>
>
>
>
> Timto si dovoluji vyzvat ostatni, aby zaslali nebo oznamili dalsi vyuziti
> OSM, ktere by se zde mohlo prezentovat:
>
> - dalsi obrazky do galerie prezentujici vyuziti (casem az bude vice 
obrazku
> se treba muze ukazat potreba prekategorizovani, pripadne muzeme vybirat 
jen
> ty lepsi)
>
> - tipy na on-line vyuziti, ktere by se resili odkazy aby tam byla videt
> prima on-line funkcnost vyuziti OSM, tady bude asi dost webu, ktere
> pouzivaji mapy podobne jako projekt Maticka Metropolis, ale protoze me ted
> zadny nenapada (i kdyz uz jsem nejake urcite videl), tak doufam ze nekoho
> neco napadne a praskne to :-)
>
> - tipy na vyber jen tech nejzajimavejsich mezinarodnich projektu (neco uz
> jsem tam naznacil ale urcite jsou i jine a patrne i zajimavejsi globalni
> vyuziti – tak pokud povazujete neco za zajimavejsi tak sem taky s tim; 
treba
> ja sam jsem nekde videl zajimavou mapu nejakeho piratkeho stylu, ale uz za
> boha nevim kde a blbec jsem si asi neulozil odkaz nebo ulozil tam kde uz o
> nem nevim, ted jsem nejakou nasel ale nebyla to ta puvodni co sla hodne
> zoomovat)
>
> - pripadne i jine typy tipu pokud uznate za vhodne ze by se na strance 
meli
> objevit
>
>
>
> Jakekoliv pripominky jsou take samozrejm vitany!
>
>
> Ahoj
> Pavel Bokr
>
> ___
> 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)
>



--
Michal Grézl
http://openstreetmap.cz(http://openstreetmap.cz)

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

Re: [Talk-cz] Galerie predevsim ceskych prikladu vyuziti OSM a vyzva k zaslani/oznameni dalsich prikladu vyuziti OSM

[Jan Dudík]

Ad pirrráti:
je tam i Karrrlštejn, Starrrá Huť, Parrrdubice, Starrré Purrrkartice,
Jarrrošov nad Nežárkou, Pernarrrec.

---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195

Dne 22. března 2016 21:37 Pavel Bokr  napsal(a):

> Ahoj,
>
> diky za tipy, doplnil jsem do galerie:
> - seznam.cz (zaklad, turistickou, zimni a zemepisnou)
> - odkaz na tripomatic (zatim pracovne tam kde je) az tam toho bude vic tak
> bych tyhle on-line sluzby oddelil asi od dalsich vyuziti
> - originalni PFko (zatim jako obrazek, “zivy” link bych uvital trvaly –
> jiz se resi, uvidime zda se vyresi)
>
> + jsem pridal ukazky stylu pirates (je tam i ten Karrrlin :-) a pencil,
> odkaz na parkovani v Praze
>
> http://openstreetmap.cz/galerie
>
>
> kazde dalsi pripominky jakoz tipy vitany, kdyz sam na neco narazim tak
> taky pridam (urcite jsem za celou tu dobu taky neco videl, ale takto
> nasilim me najednou nic nenapadne, ale casem urcite jo).
>
>
> Pavel Bokr
>
>
>
> *From:* Pavel Zbytovský 
> *Sent:* Monday, March 21, 2016 9:34 AM
> *To:* OpenStreetMap Czech Republic 
> *Subject:* Re: [Talk-cz] Galerie predevsim ceskych prikladu vyuziti OSM a
> vyzva k zaslani/oznameni dalsich prikladu vyuziti OSM
>
> Tak je hezké to ilustrovat na čr území, ale může být i jinde.. Třeba
> OpenSeaMap bych v čr neprezentoval :)))
>
> btw, ten pirátský styl normálně nabízí mapbox - tady mám stránku se všemi
> base-mapami mapboxu: http://zby.cz/parkovani
>
> P.
>
> On Mon, Mar 21, 2016 at 8:28 AM Michal Grézl <
> michal.gr...@openstreetmap.cz> wrote:
>
>> co takhle seznam pouzivajici osm mimo cr. to je asi nejdulezitejsi
>> pouziti osm v republice:)
>>
>> 2016-03-21 1:18 GMT+01:00 Pavel Bokr :
>> > Ahoj,
>> >
>> > ve spolupraci s Pavlem Zbytovskym jsem na osmap.cz vytvoril samostatnou
>> > galerii vyuziti OSM:
>> > http://openstreetmap.cz/galerie
>> >
>> > Smyslem je ukazat vyuziti OSM predevsim v ceskych projektech a ceske
>> > komunite. Zatim je to takovy zarodek, verime ze dalsi priklady budou
>> > pribyvat a stanou se dalsi inspiraci jakymi ruznymi zpusoby lze OSM
>> > vyuzivat.
>> >
>> > Na konci je teda zminka i globalnich projektech nad daty OSM, aby se
>> ukazalo
>> > alespon to nejzajimavejsi ze zahranicnich projektu (idealne nad CR). Z
>> toho
>> > zahranici by tam asi mel byt jen vyber toho opravdu nejzajimavejsiho,
>> aby
>> > bylo videt ze jake zajimave veci z toho delaji v zahranici a ze uzemi
>> CR se
>> > neresi jen v ceskych projektech. Hlavni obsah teto stranky by vsak
>> podle me
>> > melo byt ceske vyuziti.
>> >
>> >
>> >
>> >
>> > Timto si dovoluji vyzvat ostatni, aby zaslali nebo oznamili dalsi
>> vyuziti
>> > OSM, ktere by se zde mohlo prezentovat:
>> >
>> > - dalsi obrazky do galerie prezentujici vyuziti (casem az bude vice
>> obrazku
>> > se treba muze ukazat potreba prekategorizovani, pripadne muzeme vybirat
>> jen
>> > ty lepsi)
>> >
>> > - tipy na on-line vyuziti, ktere by se resili odkazy aby tam byla videt
>> > prima on-line funkcnost vyuziti OSM, tady bude asi dost webu, ktere
>> > pouzivaji mapy podobne jako projekt Maticka Metropolis, ale protoze me
>> ted
>> > zadny nenapada (i kdyz uz jsem nejake urcite videl), tak doufam ze
>> nekoho
>> > neco napadne a praskne to :-)
>> >
>> > - tipy na vyber jen tech nejzajimavejsich mezinarodnich projektu (neco
>> uz
>> > jsem tam naznacil ale urcite jsou i jine a patrne i zajimavejsi globalni
>> > vyuziti – tak pokud povazujete neco za zajimavejsi tak sem taky s tim;
>> treba
>> > ja sam jsem nekde videl zajimavou mapu nejakeho piratkeho stylu, ale uz
>> za
>> > boha nevim kde a blbec jsem si asi neulozil odkaz nebo ulozil tam kde
>> uz o
>> > nem nevim, ted jsem nejakou nasel ale nebyla to ta puvodni co sla hodne
>> > zoomovat)
>> >
>> > - pripadne i jine typy tipu pokud uznate za vhodne ze by se na strance
>> meli
>> > objevit
>> >
>> >
>> >
>> > Jakekoliv pripominky jsou take samozrejm vitany!
>> >
>> >
>> > Ahoj
>> > Pavel Bokr
>> >
>> > ___
>> > Talk-cz mailing list
>> > Talk-cz@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-cz
>> >
>>
>>
>>
>> --
>> Michal Grézl
>> http://openstreetmap.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
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] OSMIT 2016 + inaugurazione sede

[Volker Schmidt]

Ho cambiato i miei programmi e conto di esserci a Milano.

Volker

2016-02-26 18:11 GMT+01:00 Simone Cortesi :

> Ciao a tutti,
> il 21 maggio OpenStreetMap Italia inaugura la sua sede.
>
> Ci sembrava carino organizzare non solo una festicciola per tale
> occasione, ma anche di sfruttare la giornata per fare un incontro
> degli utenti OSM.
>
> Stiamo partendo in questi giorni con l'rganizzazione (e questa è la
> prima comunicazione ufficiale della cosa), ma intanto potete segnarvi
> data e luogo.
>
> DATA: 21 maggio 2016
> LUOGO: Via Bergognone angolo Via Tortona, Milano
> OSM: https://www.openstreetmap.org/way/382705324
>
> Che ne dite?
>
> ___
> 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] [UK Chapter] Definition of OSM.

[Tim Waters]

Frederik is correct in saying that OpenStreetMap Project does not
appear in the OSMF Articles of Association.

However, on the OSMF website, the following words are used: "The
Foundation supports the OpenStreetMap Project."

So the wider OSM "thing" is the OpenStreetMap Project rather than the
OpenStreetMap Community. I quite like that differentiation, even
though I cannot find the definition of what the project is!

"supports" is also a quite different meaning than "managed by"

If we wanted to have a definition that includes the OSMF: "The
OpenStreetMap Project as currently supported by the OpenStreetMap
Foundation Ltd" perhaps?

Tim

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

Re: [Talk-cz] Galerie predevsim ceskych prikladu vyuziti OSM a vyzva k zaslani/oznameni dalsich prikladu vyuziti OSM

[Pavel Bokr]

Ahoj,

diky za tipy, doplnil jsem do galerie:
- seznam.cz (zaklad, turistickou, zimni a zemepisnou)
- odkaz na tripomatic (zatim pracovne tam kde je) az tam toho bude vic tak bych 
tyhle on-line sluzby oddelil asi od dalsich vyuziti
- originalni PFko (zatim jako obrazek, “zivy” link bych uvital trvaly – jiz se 
resi, uvidime zda se vyresi)

+ jsem pridal ukazky stylu pirates (je tam i ten Karrrlin :-) a pencil, odkaz 
na parkovani v Praze

http://openstreetmap.cz/galerie


kazde dalsi pripominky jakoz tipy vitany, kdyz sam na neco narazim tak taky 
pridam (urcite jsem za celou tu dobu taky neco videl, ale takto nasilim me 
najednou nic nenapadne, ale casem urcite jo).


Pavel Bokr



From: Pavel Zbytovský 
Sent: Monday, March 21, 2016 9:34 AM
To: OpenStreetMap Czech Republic 
Subject: Re: [Talk-cz] Galerie predevsim ceskych prikladu vyuziti OSM a vyzva k 
zaslani/oznameni dalsich prikladu vyuziti OSM

Tak je hezké to ilustrovat na čr území, ale může být i jinde.. Třeba OpenSeaMap 
bych v čr neprezentoval :))) 

btw, ten pirátský styl normálně nabízí mapbox - tady mám stránku se všemi 
base-mapami mapboxu: http://zby.cz/parkovani


P.

On Mon, Mar 21, 2016 at 8:28 AM Michal Grézl  
wrote:

  co takhle seznam pouzivajici osm mimo cr. to je asi nejdulezitejsi
  pouziti osm v republice:)

  2016-03-21 1:18 GMT+01:00 Pavel Bokr :
  > Ahoj,
  >
  > ve spolupraci s Pavlem Zbytovskym jsem na osmap.cz vytvoril samostatnou
  > galerii vyuziti OSM:
  > http://openstreetmap.cz/galerie
  >
  > Smyslem je ukazat vyuziti OSM predevsim v ceskych projektech a ceske
  > komunite. Zatim je to takovy zarodek, verime ze dalsi priklady budou
  > pribyvat a stanou se dalsi inspiraci jakymi ruznymi zpusoby lze OSM
  > vyuzivat.
  >
  > Na konci je teda zminka i globalnich projektech nad daty OSM, aby se ukazalo
  > alespon to nejzajimavejsi ze zahranicnich projektu (idealne nad CR). Z toho
  > zahranici by tam asi mel byt jen vyber toho opravdu nejzajimavejsiho, aby
  > bylo videt ze jake zajimave veci z toho delaji v zahranici a ze uzemi CR se
  > neresi jen v ceskych projektech. Hlavni obsah teto stranky by vsak podle me
  > melo byt ceske vyuziti.
  >
  >
  >
  >
  > Timto si dovoluji vyzvat ostatni, aby zaslali nebo oznamili dalsi vyuziti
  > OSM, ktere by se zde mohlo prezentovat:
  >
  > - dalsi obrazky do galerie prezentujici vyuziti (casem az bude vice obrazku
  > se treba muze ukazat potreba prekategorizovani, pripadne muzeme vybirat jen
  > ty lepsi)
  >
  > - tipy na on-line vyuziti, ktere by se resili odkazy aby tam byla videt
  > prima on-line funkcnost vyuziti OSM, tady bude asi dost webu, ktere
  > pouzivaji mapy podobne jako projekt Maticka Metropolis, ale protoze me ted
  > zadny nenapada (i kdyz uz jsem nejake urcite videl), tak doufam ze nekoho
  > neco napadne a praskne to :-)
  >
  > - tipy na vyber jen tech nejzajimavejsich mezinarodnich projektu (neco uz
  > jsem tam naznacil ale urcite jsou i jine a patrne i zajimavejsi globalni
  > vyuziti – tak pokud povazujete neco za zajimavejsi tak sem taky s tim; treba
  > ja sam jsem nekde videl zajimavou mapu nejakeho piratkeho stylu, ale uz za
  > boha nevim kde a blbec jsem si asi neulozil odkaz nebo ulozil tam kde uz o
  > nem nevim, ted jsem nejakou nasel ale nebyla to ta puvodni co sla hodne
  > zoomovat)
  >
  > - pripadne i jine typy tipu pokud uznate za vhodne ze by se na strance meli
  > objevit
  >
  >
  >
  > Jakekoliv pripominky jsou take samozrejm vitany!
  >
  >
  > Ahoj
  > Pavel Bokr
  >
  > ___
  > Talk-cz mailing list
  > Talk-cz@openstreetmap.org
  > https://lists.openstreetmap.org/listinfo/talk-cz
  >



  --
  Michal Grézl
  http://openstreetmap.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-it] Coordinatori regionali

[Alessandro Palmas]

Il 22/03/2016 20:48, Francesco Placco ha scritto:

Salve a tutti,
l'idea dei coordinatori regionali mi piace molto. Ma ho un dubbio. Io 
sono Calabrese, e non c'è molta collaborazione in zona. Mantengo 
personalmente i contatti con i vari utenti e gruppi che mappano, ma si 
tratta per lo più di gruppetti autonomi, che spesso, una volta finita 
l'area, abbandonano il progetto.
Mi chiedo: ha senso proporre la candidatura? Lo farei molto 
volentieri, ma ho il timore di non trovare riscontro.


Scusate la paranoia,
buona serata



Ciao Francesco,
secondo me ha senso.

La Calabria è una delle regioni più bisognose di mappatori, avere una 
persona a cui fare riferimento per organizzare qualcosa in loco è 
importante.
Se chi mappa qualcosa (e quindi si prende la briga di capire come 
funziona OSM) poi smette, forse ha solo bisogno di stimoli per 
proseguire nella mappatura.
In lista tempo fa si diceva che forse i nuovi utenti preferiscono avere 
una mappa vuota; non penso che per tutti funzioni così, anzi ... forse 
il vedere che c'è troppo da fare porta a desistere subito. Come dire: se 
aggiungo una goccia nel mare non vedo crescere nulla, ma se sò che altri 
utenti hanno progetti di mappatura forse allora non ci mollo subito.

Se quindi metti da parte i tuoi timori  benvenuto a bordo.

Alessandro Ale_Zena_IT

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

Re: [Talk-cz] Data IPR Praha

[Jachym Cepicky]

Uvažují buď o výjimce pro OSM nebo o změně licence. Stávající licence se
jim už osvědčila, hledají něco podobného (ústní sdělení na GIS Ostrava).
Ale bohužel, nevisí to jenom na nich (jak píše Martin), je to spíš
magistrátní rozhodnutí (ale nenechávají to spát, jdou po tom)

J

út 22. 3. 2016 v 17:21 odesílatel Martin Landa 
napsal:

> Ahoj,
>
> Dne 22. března 2016 15:13 Jethro  napsal(a):
> > je zde nějaký pokrok? Rád bych podle ortofoto domapoval tramvajové trati.
> > MSF
>
> zmena licence na strane IPR bude nejakou dobu trvat (musi to projit
> magistratem). Pracuje se na tom. Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
> ___
> 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-in] parliamentry, assembly seat boundaries

[vikas yadav]

I added some comments to urban area in the talk page.

On 22 March 2016 at 15:34, Jaisen Nedumpala  wrote:

> Hi,
>
> I have made a few additions and corrections to to this page:
>
> http://wiki.openstreetmap.org/wiki/WikiProject_India/Boundaries
>
> Please have a look at that.
>
>
> 2013-12-22 18:05 GMT+05:30 Arun Ganesh :
>
>> Lets take the discussion to the wiki.
>>
>> For anyone interested to join in:
>> http://wiki.openstreetmap.org/wiki/Talk:India:Boundaries
>>
>>
>> On Sun, Dec 22, 2013 at 12:36 PM, ヴィカス ヤダヴァ (vikas yadav) <
>> mevi...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> my remarks about the proposal (also added in the talk page).
>>>
>>> Attributes
>>>
>>> There are few properties of each political boundaries:
>>>
>>>1. Elected Person
>>>2. Election Year
>>>3. ECI AC Number (ref number)
>>>4. ECI PC Number (ref number)
>>>5. ECI Ward Number (ref number)
>>>
>>> We need to support at least these in the attributes of political
>>> boundaries to support extensions which can later take data from other
>>> source or database. There are many other properties but these are the
>>> minimum.
>>> Ward boundary
>>>
>>> Ward members are also elected. Though they dont seem to be in the
>>> political boundary. Please suggest.
>>>
>>>
>>> Also, I have to checked other boundaries but even those should support
>>> some attributes that help identify that region using govt. assigned ref
>>> number for extensions.
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On 21 December 2013 22:01, Arun Ganesh  wrote:
>>>

 Thanks Jaisen.

 I have updated the wiki with the added details you mentioned:
 http://wiki.openstreetmap.org/wiki/India:Boundaries

 Please check if anything is missing and update the page as necessary.
 This is probably the most comprehensive documentation for boundary mapping
 for any country. If the scheme can accommodate India, it can probably cover
 any other country too.

 On Sat, Dec 21, 2013 at 6:27 PM, Jaisen Nedumpala 
 wrote:

> Hi,
>
> Shall I add my ideas on these boundaries?
>
> In my vision, The following are the most prominent administrative
> divisions in India:
>
> First set - Administrative boundaries
>
> 1. Territorial waters (Exclusive Economic Zone) (as per United
> Nations Convention on the Law of the Sea)
> 2. Zones (Interstate council)
> 3. States and Union Territories (Governer and Chief Minister)
> 4. Revenue Districts (District Collector)
> 5. Revenue Divisions (Revenue Divisional Officer)
> 6. Taluks / Tehsils (Tahsildar)
> 7. Revenue Villages (Village officer)
> 8. Survey / Re-survey /Un-survey - field measurement plots and sub
> divisions
>
> Second Set - Legislative boundaries
>
> 1. Lok Sabha (Parliament) Constituency [Lok Sabha - MP]
> 2. Legislative Assembly (Vidhan Sabha) Constituency [States and
> Union Territories - MLA]
>
> Third Set - Local Self Government
>
> 1. Rural
> a. District (Zilla) Panchayat (President and Secretary)
> i Divisions (Member)
> b. Development Blocks (Block/Mandal Panchayat) (President and
> Block Development Officer/Secretary)
> i Divisions (Member)
> c. Grama (Village) Panchayat ( Rural Local Authority)
> (President/Sarpanch and Secretary)
> i Wards (Member)
>
> 2. Urban
> a. Municipality / Municipal Corporation / Nagar Panchayat
> (Urban Local Authority) and Metropolitan Region (Mayor and Secretary)
> i. Zones
> ii. Wards (Councillor)
>
> 3. Cantonment area (Officer in Command)
>  (Don't know it's divisions :( (Military area Local
> Authority)
>
> Fourth Set - Courts and Police
> 1. Jurisdiction of various courts
> 2. Police Districts
> 3. Police Circles
> 3. Jurisdiction of Police Stations
>
> Fifth Set - Miscellaneous
> 1. Special Economic Zones
> 2. Coastal Regulation Zone
> 3. Ecologically Sensitive Areas
>
> I think the above listed are the important sets, regarding the
> administrative divisions of India. Besides these, almost all the 
> government
> departments of various tiers of administration, have their own internal
> administrative boundaries.
> --
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> - നെടുമ്പാല ജയ്സെന്‍ -
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> (`'·.¸(`'·.¸^¸.·'´)¸.·'´)
> «´¨`·* .  Jaisen . *..´¨`»
> (¸.·'´(`'·.¸ ¸.·'´)`'·.¸)
> ¸.·´^.`'·.¸ ¸.·'´
>  ( `·.¸`·.¸
>   `·.¸ )`·.¸
>  ¸.·(´ `·.¸
> ¸.·(.·´)`·.¸
>   ( `v´ )
> `v´
>
> 

Re: [Talk-it] Coordinatori regionali

[Francesco Placco]

Salve a tutti,
l'idea dei coordinatori regionali mi piace molto. Ma ho un dubbio. Io 
sono Calabrese, e non c'è molta collaborazione in zona. Mantengo 
personalmente i contatti con i vari utenti e gruppi che mappano, ma si 
tratta per lo più di gruppetti autonomi, che spesso, una volta finita 
l'area, abbandonano il progetto.
Mi chiedo: ha senso proporre la candidatura? Lo farei molto volentieri, 
ma ho il timore di non trovare riscontro.


Scusate la paranoia,
buona serata

--
Francesco Placco


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

Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na papire"?

[Michal Pustějovský]

Ahoj,

nedal by se používat pro stezky, které směřují z bodu A do bodu B, ale 
nejsou fyzicky značeny, tag "ktc_none=*"?


Michal

Dne 22.03.2016 v 16:42 Karel Volný napsal(a):

zdar,

...

Presto ale ani jedna z nich nema v realu zadne znaceni.

ok, vymažeme z mapy hranice krajů, protože nejsou v terénu značeny, jen sem
tam se najde nějaká cedule u silnice, například? :-)
... nebo asi jsem nepochopil, proč bylo třeba o tom takto mluvit?


a) tolik zelenych cest, ze vlastne nevim, kudy vede skutecna zelena KCT;

problém rendereru, že používá stejné barvy/typ čáry

NS by měla být čerchovaná

mimochodem mohu se zeptat autora vizuálního stylu, proč tam nakreslil vážku
místo aby použil zavedený symbol rozcestníku?


b) v mape je trasa stezky zduraznena vzitou terenni "znackou" (bily ctverec
+ zeleny sikmy pasek), takze to uzivatele navadi k hledani teto znacky
v terenu

to je jasná chyba v datech - zasloužil by za uši, kdo tam vyplnil osmc:symbol
přestože žádný není


Pak povinne vsechna zastaveni (a ty pak renderovat podobne jako rozcestniky)

proč se to má plést s rozcestníky? - pro infotabule přeci máme jinou značku

nebo to "podobně" nebylo na to, jak to má vypadat, ale že to tam vůbec má být?
- no to samozřejmě

K.


___
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] OSMAnd Live

[Cascafico Giovanni]

Peccato che non accettino i nuovi indirizzi bitcoin (iniziano per 3 invece
che 1)... A quest'ora sarei ricco sfondato :D

--
cascafico.altervista.org
twitter.com/cascafico
Il 22/mar/2016 13:49 "Francesco Pelullo"  ha scritto:

>
> Il 22 mar 2016 13:33, "Luca Delucchi"  ha scritto:
> >
> >
> > cosa vuol dire che il 70% va ai contributors di OSM registrati?
> >
> >
>
> Che se ti registri al loro servizio come contributor OSM e fornisci un
> indirizzo bitcoin, ti versano una quota dei profitti derivanti dal servizio
> a pagamento.
>
> La quota dipende dal tuo "ranking" OSM e dal fatto che i donatori possono
> destinare le quote ad una regione preferita.
>
> Ciao
> /nubii/
>
> ___
> 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-it] OSMAnd Live

[girarsi_liste]

Il 22/03/2016 14:58, Andrea Albani ha scritto:
> Ciao,
> 
> premetto che per me l'idea di dare soldi ai contributor ha come effetto
> collaterale quello di incentivare (potenzialmente) un editing che poco
> avrebbe a che fare con la qualità, ma più con la quantità.
> 
> Non trovate ?
> 
> Detto questo... hai un'idea di come funziona il ranking ?
> Guardando le statistiche mi sembra che conteggino il numero di changeset.
> 
> Se così fosse lo trovo fuorviante perchè quel numero vuol dire veramente
> poco e penalizza chi fa editing con pochi changeset "pesanti", magari
> contribuendo maggiormente alla causa.
> 
> Senza citare nomi...se guardate ad esempio le prime posizioni nelle
> statistiche della Lombardia  - Marzo 2016 trovate utenti con profili di
> contribuzione (che potete verificare tramite i tool di neis-one) molto
> diversi, ma che si ritrovano con lo stesso ranking.
> 
> Ciao
> 
> 

Ma perchè non li danno direttamente ad OSM?

-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [Talk-in] Boundary tagging scheme for India

[Arun Ganesh]

My feedback on the current state of the proposal:

# Admin Boundaries

This looks good overall. The important aspect about admin boundaries is
that they are fairly static and do not change unless through legislation.
Is this understanding correct?

I would correct the admin_level values to closely match the same values
used for countries around the world[1]. 2=national, 4=state, 6=district,
8=sub district, 10=revenue village (The odd numbers used for any groupings
in between)

# Political Boundaries

Boundaries defined by the election commission and redrawn after each census
by the Delimitation Commission [2]. The list currently covers the
parliament and assembly constituencies, but no boundaries for local bodies.

These boundaries do not coincide with administrative boundaries, except
maybe at the state level (admin_level=4)

# Self governance boundaries

These are technically political boundaries for self governance, according
to the Panchayati Raj system[3] and Municapal bodies.

This is currently divided into rural and urban boundaries, but can probably
be conflated together. It might also make sense to use a political_division
value that matches the admin boundaries:

Rural:
6=district/zilla panchayat, 8=block/subdistrict/mandal panchayat,
10=village/gram panchayat, 11=neighbourhood/ward gram sabha

Urban:
6=city/town municipal body, 8=sub city/municipal zones, 10=suburb/municipal
ward, 11=neighborhood/colony mohalla

Jaisen, would be great to hear your feedback on this.


[1]
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
[2] http://eci.nic.in/delim/Acts/acts.asp
[3] http://www.panchayat.gov.in/ebook/
[4] https://en.wikipedia.org/wiki/Municipal_governance_in_India


On Tue, Mar 22, 2016 at 9:31 PM, Arun Ganesh 
wrote:

> Merging recent discussions from district[1] and constituency [2]
> boundaries.
>
> The current tagging scheme for boundaries in India[3]  has limitations
> since it was not effectively researched to properly separate revenue and
> local body boundaries.
>
> This is the reason to draw up a more well researched proposal[4]
>
> Jaisen, who has experience working with the panchayat office in Kerala has
> just made the proposal more comprehensive[5]. This is right now the most
> detailed description of various boundaries in India that one can find
> anywhere online.
>
> This is a great time to get more eyes on this and work towards a final
> scheme.
>
>
> [1]
> https://lists.openstreetmap.org/pipermail/talk-in/2016-March/002529.html
> [2]
> https://lists.openstreetmap.org/pipermail/talk-in/2016-March/002533.html
>
> [3]
> http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
> [4] http://wiki.openstreetmap.org/wiki/WikiProject_India/Boundaries
> [5]
> http://wiki.openstreetmap.org/w/index.php?title=WikiProject_India/Boundaries=next=1280759
>
> --
> Arun Ganesh
> @planemad
> 
>



-- 
Arun Ganesh
@planemad

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

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[David Fawcett]

I think that this would be a great Maproulette subject!



> On Mar 22, 2016, at 9:23 AM, Maarten Deen  wrote:
> 
>> On 2016-03-22 14:10, Frank Villaro-Dixon wrote:
>> 
>> # First goal:
>> First goal is quite simple. The idea is to work only on relations
>> which have a natural=water .  Then, it will:
>>* Delete natural=water from all the ways if they are NOT closed or
>> ring 0.
> 
> I have been fixing waterways and water areas in the New Orleans area. I think 
> most problems are due to a botched import. There are a number of unclosed 
> areas, some water, some wetland. They just need to be closed which sometimes 
> is just connecting the last two dots, sometimes it is merging two ways.
> 
> It would be very unhelpful if the natural=water tags of these ways would be 
> deleted. Then you have to go search in the history to see what it was. Is it 
> natural=water or natural=wetland? It would increase the workload in fixing 
> this.
> 
> Please, do not do this. You can flag them as defective so that someone has a 
> look, but don't delete the tags.
> 
> Since deleting tags from unclosed ways does not solve anything (and IMHO 
> makes things worse), this should be done manually. It would be a perfect case 
> to enter in maproulette 
> 
> Regards,
> Maarten
> 
> 
> ___
> 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-GB] UK chapter

[Brian Prangle]

Hi everyone

Anyone wishing to be listed as a founder member on the incorporation
documents to be registered at Companies House please send your full name
and address to "osmuk at nomoregrapes.com" . In case anyone wonders whose
address this is: it's Gregory Marler's

I guess legally that entitles you to attend the first meeting (probably
online) where various setting-up things have to be done - like electing
officers, confirming the directors, opening a bank account and setting the
membership subscriptions.

Regards

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

[Talk-GB] Nottingham Pub Meetup tonight 19:30

[SK53]

At the Lincolnshire Poacher as usual.

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

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[malenki]

On Tue, 22 Mar 2016 15:12:42 +0100,
Frank Villaro-Dixon wrote:
> >Mappers frequently map things in ambiguous ways or change existing
> >mapping in ways that make it ambiguous and it is hard to decide from
> >the data alone how to interpret such mapping.  A bot will not be any
> >better in doing that than a human mapper and you would destroy any
> >chance of actually determining the original intent of the mapper with
> >such edits.  
> Can you give me an example ?

Example:
Think of an MP where the way has – additionally to the tags you want to
fix – intermittent=yes and the relation has not.

Would your script really enhance the situation?
Does your script even take in consideration if the ways are inner or
outer?

> This algorithm won't loose any information. It's merely deleting 
> duplicates, so where is the problem ?

Where is the problem /not/ to fix this by script, then?

Recently I was told by somebody: Deleting data is not a real deletion
in OSM. It is just hiding that data. 

Subjective that may be true like your statement above – but it makes
editing harder without adding any value.

You already caused a lot of additional work (review of your edits and
reverts) and time used for discussions.
Why not stop replying mails here reflex-like and start to think about
the problem? Again? With the new information you were given? And
without trying to squeeze all the information in your scheme of thinking
(or "problem solving").

Thomas



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

Re: [Talk-cz] Data IPR Praha

[Martin Landa]

Ahoj,

Dne 22. března 2016 15:13 Jethro  napsal(a):
> je zde nějaký pokrok? Rád bych podle ortofoto domapoval tramvajové trati.
> MSF

zmena licence na strane IPR bude nejakou dobu trvat (musi to projit
magistratem). Pracuje se na tom. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

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

[Talk-in] Boundary tagging scheme for India

[Arun Ganesh]

Merging recent discussions from district[1] and constituency [2] boundaries.

The current tagging scheme for boundaries in India[3]  has limitations
since it was not effectively researched to properly separate revenue and
local body boundaries.

This is the reason to draw up a more well researched proposal[4]

Jaisen, who has experience working with the panchayat office in Kerala has
just made the proposal more comprehensive[5]. This is right now the most
detailed description of various boundaries in India that one can find
anywhere online.

This is a great time to get more eyes on this and work towards a final
scheme.


[1] https://lists.openstreetmap.org/pipermail/talk-in/2016-March/002529.html
[2] https://lists.openstreetmap.org/pipermail/talk-in/2016-March/002533.html

[3]
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
[4] http://wiki.openstreetmap.org/wiki/WikiProject_India/Boundaries
[5]
http://wiki.openstreetmap.org/w/index.php?title=WikiProject_India/Boundaries=next=1280759

-- 
Arun Ganesh
@planemad

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

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[Pierre Béland]

On 2016-03-22 14:10, Frank Villaro-Dixon wrote:


># First goal:
>First goal is quite simple. The idea is to work only on relations
>which have a natural=water .  Then, it will:
>    * Delete natural=water from all the ways if they are NOT closed or 
>    ring 0.
>

This is a good proposition to look at unclosed polygons and see if a potential 
incorrect keys to fix. 

I agree with others that using a Bot is not a safe way to handle these 
problems. Could a script to extract such unclosed polygons be proposed?  This 
way, each local community could take care to fix data for their area, importing 
and examining the data in the JOSM Editor. The Todo plugin could be used to go 
through the items to correct. 
Pierre 

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

Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na papire"?

[Karel Volný]

zdar,

...
> Presto ale ani jedna z nich nema v realu zadne znaceni.

ok, vymažeme z mapy hranice krajů, protože nejsou v terénu značeny, jen sem 
tam se najde nějaká cedule u silnice, například? :-)
... nebo asi jsem nepochopil, proč bylo třeba o tom takto mluvit?

> a) tolik zelenych cest, ze vlastne nevim, kudy vede skutecna zelena KCT;

problém rendereru, že používá stejné barvy/typ čáry

NS by měla být čerchovaná

mimochodem mohu se zeptat autora vizuálního stylu, proč tam nakreslil vážku 
místo aby použil zavedený symbol rozcestníku?

> b) v mape je trasa stezky zduraznena vzitou terenni "znackou" (bily ctverec
> + zeleny sikmy pasek), takze to uzivatele navadi k hledani teto znacky
> v terenu

to je jasná chyba v datech - zasloužil by za uši, kdo tam vyplnil osmc:symbol 
přestože žádný není

> Pak povinne vsechna zastaveni (a ty pak renderovat podobne jako rozcestniky)

proč se to má plést s rozcestníky? - pro infotabule přeci máme jinou značku

nebo to "podobně" nebylo na to, jak to má vypadat, ale že to tam vůbec má být? 
- no to samozřejmě

K.


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

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[Christoph Hormann]

On Tuesday 22 March 2016, Frank Villaro-Dixon wrote:
>
> Can you give me an example ?

I probably could (after all i am on record for saying waterbody mapping 
in OSM is a practical case of the infinite monkey theorem) but right 
now i don't have the time to look for a good real world example.

In principle many cases where the way you'd remove a tag from has 
additional tags the meaning of those tags will change when you remove a 
tag.  Also cases where the way in question forms the division between 
two water areas you will usually run into trouble.

On a principal level removing an ambiguity will always mean you remove 
possible interpretations of the data and your bot simply cannot know if 
the interpretations it removes are actually incorrect and the remaining 
interpretation is the correct one.

> This algorithm won't loose any information. It's merely deleting
> duplicates, so where is the problem ?

You are only looking at it from a formal side and based on a specific, 
subjective interpretation of tagging rules which is not appropriate.  
See also 

http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

As others have said the best way to improve waterbody data in OSM is by 
actually doing mapping work and correcting errors based on local 
knowledge or imagery.  You can believe me when i say that factual 
errors and inaccuracies are much more common and harmful problems 
w.r.t. water area mapping than basic tagging inconsistencies.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-GB] UK Chapter: Who will be the "we"?

[Brian Prangle]

Dave

At its narrowest - the members who pay the subscription
At its widest - anyone who produces or uses OSM data in the UK

Regards

Brian

On 21 March 2016 at 00:40, Dave F  wrote:

> Hi all
>
> OK, this a genuine, non rhetorical, non cynical question.
>
> I've loosely been following the discussions of setting up a UK:chapter of
> OSM.
>
> After you've decided upon the process you all want to take & when you've
> started writing documents & sending emails out to the wider world, who will
> be the "we", as in "we feel OSM is doing this incorrectly/correctly?
>
> Who are the OSM contributors you believe you will represent?
>
> Thanks
> Dave F.
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> 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] [BOT] [RFC]: water surfaces

[Andy Townsend]

On 22/03/2016 13:10, Frank Villaro-Dixon wrote:

Hi everybody,


So, what do you think ?


I think it's a silly idea.

Identifying complex potentially problem areas is one thing - as you've 
found, attempting to fix them automatically is quite another.  In among 
the "obvious" fixes will be many harder to find new problems that you 
have introduced.





Technically, it was already run on the whole planet, and so far no 
bugs were found. 


That's not true.  Many people complained and all your work was reverted.*



Now, I need your comments and/or your approval, critiques, etc.
Tell me what you think ;-)



Here's what I think you should do, when you detect a potential problem:

1) Firstly, before fixing anything, try and understand what the cause 
was.  Perhaps an inexperienced mapper has edited some existing data that 
broke something that they didn't understand?  You'll need to look at the 
mappers who have contributed to the problem, their relative experience, 
and what editors they are using (for example, an iD user may been not 
have seen the complicated reationship between multipoloygons, and a JOSM 
user may have stopped thinking about real-world data and thought _only_ 
in terms of multipolygons - both can cause errors).


2) If you can, go and actually survey the area.  No, really, do actually 
go there.  That way you'll get a full 3d picture in your head of what's 
there and how it relates to the aerial imagery.  It also enables you to 
recognise features from imagery better, so you can see what sort of 
surface a path is, and (with water features) tell man-made ones from 
natural rivers and streams (difficult from imagery, especially when made 
by man 200 years ago).  Maybe the area is inaccessible to everyone, in 
which case anyone would have to work from imagery and other out of 
copyright sources, but if it is accessible to local mappers then they 
are the best people to fix any problem because they will be able to do a 
proper survey.


3) You'll now have a picture of (a) what the original mapper had in mind 
when they mapped it, (b) what subsequent mappers were trying to do and 
(c) what you'd have mapped it as, if you had mapped it from scratch.


If these three all agree, and it was just a tagging error (for example 
I've seen people add "natural=foo" instead of "name=foo" recently) then 
it makes sense to "just correct the data".  However, it's quite likely 
that these three might disagree, and perhaps you need to explain to an 
earlier mapper how multipolygons work, or to someone who has come along 
and "corrected" data in the interim that what they've changed something 
to is a valid OSM tag, but doesn't actually match what's on the ground 
in this case.


The best way to try and communicate with a specific previous mapper is 
via a changeset discussion comment.  The advantages of doing it this way 
are that the discussion is public, and the context is obvious, as it's 
visible with the changeset.  Other local mappers can also add comments 
there too - perhaps someone else locally has more knowledge about a 
particular water body.  If that doesn't work, or you need to contact all 
local mappers you can try adding an OSM note explaining the issue.  This 
might not get picked up immediately but notes sometimes do get fixed 
many months after they were added. Another option is to try and contact 
local users via a country's mailing list, forum or IRC channel.  They 
may know someone who is local, or know someone who knows someone (not 
necessarily an OSMer) who may be able to answer questions.



Based on the above, I don't believe that it is possible to do the sort 
of "water fixup" that you were trying to do entirely automatically. 
http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct has 
sections that require you to "document and discuss your plans" for a 
reason.  To take a specific example, I noticed local edits made by you 
in http://www.openstreetmap.org/changeset/37086092 that simply failed to 
understand what the original mapper was trying to represent.  I pointed 
this out on the changeset discussion, and was frankly amazed when you 
created a bot account to make more of exactly the same sort of error, 
again.  Maybe I'm the frog in 
https://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog :)


There may be many scenarios that you haven't considered when designed 
what automatic changes you are trying to make.  Other mappers will be 
able to help you understand those when you discuss your plans with them.


Also, please don't think that "changing a tag to one that is valid 
within OSM" means "making the data correct" - it doesn't.  All it means 
is that it is no longer possible to automatically find potentially 
problematical areas needing survey, or find mappers who may need help to 
map better.  In an analogy, if someone has described a "horse" as a 
"kow" correcting the spelling to "cow" does not make the description 
correct.


Finally, please remember - 

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[Frank Villaro-Dixon]

On 16-03-22 15:23:44, Maarten Deen, wrote 1.7K characters saying:

On 2016-03-22 14:10, Frank Villaro-Dixon wrote:


# First goal:
First goal is quite simple. The idea is to work only on relations
which have a natural=water .  Then, it will:
	* Delete natural=water from all the ways if they are NOT closed or 
	ring 0.


I have been fixing waterways and water areas in the New Orleans area. 
I think most problems are due to a botched import. There are a number 
of unclosed areas, some water, some wetland. They just need to be 
closed which sometimes is just connecting the last two dots, sometimes 
it is merging two ways.


Again: this bot will be applied ONLY to ways belonging to a relation ! So 
the water areas are already valid. What is the problem then ?


It would be very unhelpful if the natural=water tags of these ways 
would be deleted. Then you have to go search in the history to see 
what it was. Is it natural=water or natural=wetland? It would increase 
the workload in fixing this.


Please, do not do this. You can flag them as defective so that someone 
has a look, but don't delete the tags.

The idea is not to touch defective water surfaces.



Since deleting tags from unclosed ways does not solve anything (and 
IMHO makes things worse), this should be done manually. It would be a 
perfect case to enter in maproulette 


Can you give me an example too ? It's WRONG to have a tag in a way AND in 
a relation.


For example, take this relation:
https://www.openstreetmap.org/relation/5474652
It has:
natural=water
water=lake

and a way:
https://www.openstreetmap.org/way/368404998
which also has:
natural=water
water=lake

and it is WRONG. Only the relation should have these attributes. Where is 
the problem then ?


Thanks,

Frank

--
frank.villaro-dixon.eu   - PGP: 6F36914A
Envie d'électricité 100% verte ? Enercoop.fr
What is a Velomobile ?   www.sans-essence.eu

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

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[Maarten Deen]

On 2016-03-22 14:10, Frank Villaro-Dixon wrote:


# First goal:
First goal is quite simple. The idea is to work only on relations
which have a natural=water .  Then, it will:
	* Delete natural=water from all the ways if they are NOT closed or 
	ring 0.


I have been fixing waterways and water areas in the New Orleans area. I 
think most problems are due to a botched import. There are a number of 
unclosed areas, some water, some wetland. They just need to be closed 
which sometimes is just connecting the last two dots, sometimes it is 
merging two ways.


It would be very unhelpful if the natural=water tags of these ways would 
be deleted. Then you have to go search in the history to see what it 
was. Is it natural=water or natural=wetland? It would increase the 
workload in fixing this.


Please, do not do this. You can flag them as defective so that someone 
has a look, but don't delete the tags.


Since deleting tags from unclosed ways does not solve anything (and IMHO 
makes things worse), this should be done manually. It would be a perfect 
case to enter in maproulette 


Regards,
Maarten


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

Re: [Talk-cz] Data IPR Praha

[Jethro]

Ahoj,
je zde nějaký pokrok? Rád bych podle ortofoto domapoval tramvajové trati.
MSF
Jethro

2016-03-05 11:27 GMT+01:00 Martin Landa :
> Dne 5. března 2016 0:05 Petr Vejsada  napsal(a):
>> ty záchody jsou i na Geoportálu Praha jako otevřená data.
>
> ano, ale pod licenci CC BY-SA 4.0 [1], ktera, jak jsem pochopil, neni
> kompatiblni s ODbL. Mam studenta, ktery se tomu bude venovat v ramci
> Bp a jsem v kontaktu s IPR (snaha resit situaci je). Ma
>
> [1] 
> http://www.geoportalpraha.cz/cs/clanek/276/licencni-podminky-pro-otevrena-data#.Vtqzm0Ki7MU
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
> ___
> 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] [BOT] [RFC]: water surfaces

[Frank Villaro-Dixon]

On 16-03-22 14:53:42, Christoph Hormann, wrote 1.9K characters saying:

On Tuesday 22 March 2016, Frank Villaro-Dixon wrote:


# Why ?
Well, OSM has a quite exhaustive lakes/water surfaces database, but
it's a complete pain to work on because:
* Some non closed ways have a natural=water or a water=* tag,
which makes no sense and is forbidden.
* Attributes (natural, water, name, intermittent) are in the
relation and in the way itself, which is anti normal form (and not
logical).

# First goal:
First goal is quite simple. The idea is to work only on relations
which have a natural=water .  Then, it will:
* Delete natural=water from all the ways if they are NOT closed or
ring 0.
* delete the corresponding water=x IF the relation has the same
tag



Mappers frequently map things in ambiguous ways or change existing
mapping in ways that make it ambiguous and it is hard to decide from
the data alone how to interpret such mapping.  A bot will not be any
better in doing that than a human mapper and you would destroy any
chance of actually determining the original intent of the mapper with
such edits.

Can you give me an example ?

This algorithm won't loose any information. It's merely deleting 
duplicates, so where is the problem ?





--
frank.villaro-dixon.eu   - PGP: 6F36914A
Envie d'électricité 100% verte ? Enercoop.fr
What is a Velomobile ?   www.sans-essence.eu

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

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[Frank Villaro-Dixon]

On 16-03-22 10:23:51, Nicolás Alvarez, wrote 1.2K characters saying:



El 22 mar 2016, a las 10:10, Frank Villaro-Dixon  
escribió:

# First goal:
First goal is quite simple. The idea is to work only on relations which have a 
natural=water .  Then, it will:
   * Delete natural=water from all the ways if they are NOT closed orring 0.


What if there is a way legitimately with natural=water that isn't closed 
because of an error? The correct fix is to close it, not to remove the tag. 
This cannot be done automatically.

It doesn't matter because this way will also be referenced by a relation 
which has the natural=water tag. Thus, it can be removed from the way.


(didn't reply to the list)

--
frank.villaro-dixon.eu   - PGP: 6F36914A
Envie d'électricité 100% verte ? Enercoop.fr
What is a Velomobile ?   www.sans-essence.eu

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

Re: [Talk-it] OSMAnd Live

[Andrea Albani]

Ciao,

premetto che per me l'idea di dare soldi ai contributor ha come effetto
collaterale quello di incentivare (potenzialmente) un editing che poco
avrebbe a che fare con la qualità, ma più con la quantità.

Non trovate ?

Detto questo... hai un'idea di come funziona il ranking ?
Guardando le statistiche mi sembra che conteggino il numero di changeset.

Se così fosse lo trovo fuorviante perchè quel numero vuol dire veramente
poco e penalizza chi fa editing con pochi changeset "pesanti", magari
contribuendo maggiormente alla causa.

Senza citare nomi...se guardate ad esempio le prime posizioni nelle
statistiche della Lombardia  - Marzo 2016 trovate utenti con profili di
contribuzione (che potete verificare tramite i tool di neis-one) molto
diversi, ma che si ritrovano con lo stesso ranking.

Ciao




Il giorno 22 marzo 2016 13:24, Federico Cortese  ha
scritto:

> Segnalo che col nuovo update di OSMAnd è disponibile la OSM Live
> subscription.
>
> http://osmand.net/osm_live#information
>
> Riassumendo in poche parole chi vuole usufruire del servizio paga una
> quota mensile di 1,22 € per avere le mappe aggiornate con cadenza
> oraria. Del pagamento eseguito il 30% va agli sviluppatori di OSMAnd,
> mentre il restante 70% ai contributors di OSM registrati.
> Mi sembra uno sviluppo interessante.
>
> Ciao
> Federico
>
> ___
> 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

[Talk-it] Assemblea Wikimedia Italia, 9 aprile, Firenze

[Federico Leva (Nemo)]

Poiché qualcuno ha espresso interesse a essere notificato in lista: la 
prossima assemblea di Wikimedia Italia aka OpenStreetMap Italia sarà il 
9 aprile a Firenze.


https://it.wikipedia.org/wiki/Wikipedia:Raduni/Firenze_2016_-_Assemblea_Wikimedia_Italia

L'odg comprende l'approvazione del bilancio e il rinnovo del direttivo; 
si può votare anche "in remoto" delegando un/una partecipante.


Nemo

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

Re: [OSM-talk] [BOT] [RFC]: water surfaces

[Christoph Hormann]

On Tuesday 22 March 2016, Frank Villaro-Dixon wrote:
>
> # Why ?
> Well, OSM has a quite exhaustive lakes/water surfaces database, but
> it's a complete pain to work on because:
>   * Some non closed ways have a natural=water or a water=* tag,
>   which makes no sense and is forbidden.
>   * Attributes (natural, water, name, intermittent) are in the
>   relation and in the way itself, which is anti normal form (and not
> logical).
>
> # First goal:
> First goal is quite simple. The idea is to work only on relations
> which have a natural=water .  Then, it will:
>   * Delete natural=water from all the ways if they are NOT closed or
>   ring 0.
>   * delete the corresponding water=x IF the relation has the same
>   tag

This is not going to work ('work' in the sense of turning incorrect 
information into correct information with some reasonable degree of 
reliability).

Mappers frequently map things in ambiguous ways or change existing 
mapping in ways that make it ambiguous and it is hard to decide from 
the data alone how to interpret such mapping.  A bot will not be any 
better in doing that than a human mapper and you would destroy any 
chance of actually determining the original intent of the mapper with 
such edits.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-GB] UK Chapter: Who will be the "we"?

[Tim Waters]

Hi Dave,

I think that the "we" would be the members of the organization.

Tim

On 21 March 2016 at 00:40, Dave F  wrote:
> Hi all
>
> OK, this a genuine, non rhetorical, non cynical question.
>
> I've loosely been following the discussions of setting up a UK:chapter of
> OSM.
>
> After you've decided upon the process you all want to take & when you've
> started writing documents & sending emails out to the wider world, who will
> be the "we", as in "we feel OSM is doing this incorrectly/correctly?
>
> Who are the OSM contributors you believe you will represent?
>
> Thanks
> Dave F.
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> 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] [BOT] [RFC]: water surfaces

[Nicolás Alvarez]

> El 22 mar 2016, a las 10:10, Frank Villaro-Dixon  
> escribió:
> 
> Hi everybody,
> 
> I launched a bot (FrankVD_bot) this week which didn't make everyone happy, as 
> it wasn't discussed with the community, which is quite normal. Here's then 
> the RFC for (let's call it) scorpion.
> 
> 
> # Targets
> The targeted zones are actually the multipolygons with natural=water on them. 
> Working box is all the planet.
> 
> # Why ?
> Well, OSM has a quite exhaustive lakes/water surfaces database, but it's a 
> complete pain to work on because:
>* Some non closed ways have a natural=water or a water=* tag,which 
> makes no sense and is forbidden.
>* Attributes (natural, water, name, intermittent) are in therelation 
> and in the way itself, which is anti normal form (and not logical).
> 
> # First goal:
> First goal is quite simple. The idea is to work only on relations which have 
> a natural=water .  Then, it will:
>* Delete natural=water from all the ways if they are NOT closed orring 
> 0.

What if there is a way legitimately with natural=water that isn't closed 
because of an error? The correct fix is to close it, not to remove the tag. 
This cannot be done automatically.


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

[OSM-talk] [BOT] [RFC]: water surfaces

[Frank Villaro-Dixon]

Hi everybody,

I launched a bot (FrankVD_bot) this week which didn't make everyone happy, 
as it wasn't discussed with the community, which is quite normal. Here's 
then the RFC for (let's call it) scorpion.



# Targets
The targeted zones are actually the multipolygons with natural=water on 
them. Working box is all the planet.


# Why ?
Well, OSM has a quite exhaustive lakes/water surfaces database, but it's a 
complete pain to work on because:
	* Some non closed ways have a natural=water or a water=* tag, 
	which makes no sense and is forbidden.
	* Attributes (natural, water, name, intermittent) are in the 
	relation and in the way itself, which is anti normal form (and not 
logical).


# First goal:
First goal is quite simple. The idea is to work only on relations which 
have a natural=water .  Then, it will:
	* Delete natural=water from all the ways if they are NOT closed or 
	ring 0.
	* delete the corresponding water=x IF the relation has the same 
	tag


# Possible bugs:
Some people thought that there was a bug as it was deleting water=* tags, 
but in fact there is not as the tag is already carried by the relation, so 
no need to have it there.


# Sources:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
http://wiki.openstreetmap.org/wiki/Key:water

# Source code:
Source code (php + bash) is available either:
* via web interface: http://git.vi-di.fr/gitphp/?p=OSM_bot.git
* via git: git clone git://git.vi-di.fr/OSM_bot.git

# Future work
It would be great to then support more tags (like migrating boat, 
intermittent, …) migrating to the relation, but I think that in order to 
keep things clear, it should be made afterwards. Does that seem ok ?



So, what do you think ?

Technically, it was already run on the whole planet, and so far no bugs 
were found. Now, I need your comments and/or your approval, critiques, 
etc.

Tell me what you think ;-)


Thanks,

Cheers,

Frank



--
frank.villaro-dixon.eu   - PGP: 6F36914A
Envie d'électricité 100% verte ? Enercoop.fr
What is a Velomobile ?   www.sans-essence.eu

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

Re: [OSM-talk] JOSM plugin to import GeoJSON?

[Jukka Rahkonen]

Frederik Ramm  remote.org> writes:

> 
> Hi,
> 
> On 03/20/2016 10:56 PM, Stefan Keller wrote:
> > But Shapefile remains an oldtimer with more drawbacks than limited
> > field names; see [1].
> > GeoJSON (ascii) and GeoPackages (binary) are formats which are more
> > suited for the job.
> > I still have hope that JOSM will be able to read those vector formats too.
> 
> Frankly, whenever I venture into the brave new world of Spatialite, I
> come back to good old shape files after a while for performance reasons.
> I'm not sure if Geopackage has significant performance improvements over
> simple Spatialite but if it hasn't then my recommendation for simple GIS
> processing is certainly to stick with shape files for the time being -
> despite all their shortcomings.


Hi Frederic,

I would like to receive some sample data, exact way to reproduce some of
your ventures and cold numbers about the speed you have experienced.
Spatialite does have it's limits but for plain selects with spatial and
attribute filters it can well outperform both shapefiles and PostGIS. 

I keep most vector data for WMS services in Spatialite or GeoPackage due to
the already mentioned and some other reasons:
- supports long attribute names
- supports strings longer than 255 characters
- supports SQL
- supports attribute indexes
- much less encoding problems due to UTF-8
- one single file vs. a bunch of files in shapefile, perhaps even split to
separate bunches for points, lines and polygons.

For me SpatiaLite is a little bit slower than shapefiles if only spatial
filter (BBOX) is used but usually faster if also attribute filters are
involved, especially if more than one field is needed in filters (Shapefiles
can be sorted by one attribute only). Of course spatialite must have indexes
which suit the queries and when it comes to spatial index, the client must
know how to utilize the table based R-Tree index. I also recommend to VACUUM
once the database is ready to use.

Many spatial operations are relatively slow in Spatialite and I don't
usually utilize them on-the-fly with WMS server. Instead, I run the
algorithm once and store the result into a new table because a few
mega/gigabytes of additional disk space is not crucial on the server. 
However, such operations tend to be slow also if shapefiles are used as
source data.

Write performance especially with concurrent writes is another story. I am
talking about read-only operations. I know that I am writing empty words as
far as I do not include reproducible facts but I am willing to join to a
controlled test if someone is organizing such.

-Jukka Rahkonen-




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

Re: [Talk-it] OSMAnd Live

[Francesco Pelullo]

Il 22 mar 2016 13:33, "Luca Delucchi"  ha scritto:
>
>
> cosa vuol dire che il 70% va ai contributors di OSM registrati?
>
>

Che se ti registri al loro servizio come contributor OSM e fornisci un
indirizzo bitcoin, ti versano una quota dei profitti derivanti dal servizio
a pagamento.

La quota dipende dal tuo "ranking" OSM e dal fatto che i donatori possono
destinare le quote ad una regione preferita.

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

Re: [Talk-it] OSMAnd Live

[Francesco Pelullo]

Il 22 mar 2016 1:25 PM, "Federico Cortese"  ha
scritto:
>

> mentre il restante 70% ai contributors di OSM registrati.
>
>

"... according to their ranking..."
Questo non l'ho capito.

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

Re: [Talk-it] OSMAnd Live

[Luca Delucchi]

Ciao,

2016-03-22 13:24 GMT+01:00 Federico Cortese :
> Segnalo che col nuovo update di OSMAnd è disponibile la OSM Live subscription.
>
> http://osmand.net/osm_live#information
>
> Riassumendo in poche parole chi vuole usufruire del servizio paga una
> quota mensile di 1,22 € per avere le mappe aggiornate con cadenza
> oraria. Del pagamento eseguito il 30% va agli sviluppatori di OSMAnd,
> mentre il restante 70% ai contributors di OSM registrati.

cosa vuol dire che il 70% va ai contributors di OSM registrati?

> Mi sembra uno sviluppo interessante.
>
> Ciao
> Federico
>



-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

[Talk-it] OSMAnd Live

[Federico Cortese]

Segnalo che col nuovo update di OSMAnd è disponibile la OSM Live subscription.

http://osmand.net/osm_live#information

Riassumendo in poche parole chi vuole usufruire del servizio paga una
quota mensile di 1,22 € per avere le mappe aggiornate con cadenza
oraria. Del pagamento eseguito il 30% va agli sviluppatori di OSMAnd,
mentre il restante 70% ai contributors di OSM registrati.
Mi sembra uno sviluppo interessante.

Ciao
Federico

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

Re: [Talk-it] Nuovo metodo per processare i dati GPS

[Martin Koppenhoefer]

2016-03-22 12:42 GMT+01:00 Federico Cortese :

> Grazie Martin, molto interessante anche se non è spiegato come ci
> siano riusciti.
>



scusate, questo è il paper:
https://www.researchgate.net/publication/286498140_Computationally_Efficient_Carrier_Integer_Ambiguity_Resolution_in_Multiepoch_GPSINS_A_Common-Position-Shift_Approach

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

Re: [Talk-it] Nuovo metodo per processare i dati GPS

[Pio]

Interessante, stiamo a vedere le ricadute sul mercato!



--
View this message in context: 
http://gis.19327.n5.nabble.com/Nuovo-metodo-per-processare-i-dati-GPS-tp5870402p5870404.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Nuovo metodo per processare i dati GPS

[Federico Cortese]

2016-03-22 12:24 GMT+01:00 Martin Koppenhoefer :
> Segnalo questo articolo (in inglese):
> https://www.sciencedaily.com/releases/2016/02/16021507.htm
>
> La University of California ha sviluppato un nuovo metodo per calcolare la
> posizione da dati GPS, il quale dovrebbe consentire di ottenere una
> precisione di pochi centimetri senza aumentare il fabbisogno energetico.
>

"Farrell said these requirements can be achieved by combining GPS
measurements with data from an inertial measurement unit (IMU) through
an internal navigation system (INS). In the combined system, the GPS
provides data to achieve high accuracy, while the IMU provides data to
achieve high sample rates and high bandwidth continuously.

Achieving centimeter accuracy requires "GPS carrier phase integer
ambiguity resolution." Until now, combining GPS and IMU data to solve
for the integers has been computationally expensive, limiting its use
in real-world applications. The UCR team has changed that, developing
a new approach that results in highly accurate positioning information
with several orders of magnitude fewer computations."

Grazie Martin, molto interessante anche se non è spiegato come ci
siano riusciti. Speriamo venga implementato presto!

Ciao
Federico

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

[Talk-it] Nuovo metodo per processare i dati GPS

[Martin Koppenhoefer]

Segnalo questo articolo (in inglese):
https://www.sciencedaily.com/releases/2016/02/16021507.htm

La University of California ha sviluppato un nuovo metodo per calcolare la
posizione da dati GPS, il quale dovrebbe consentire di ottenere una
precisione di pochi centimetri senza aumentare il fabbisogno energetico.

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

[OSRM-talk] Demo server switchover to OSRM 5.0 and new HTTP API

[Johan Uhle]

Hi All,

some of you are using the demo server at https://router.project-osrm.org in
your own projects. This message is to notify you of upcoming changes there.

For a while we've been working on OSRM 5.0.0, which will bring big changes
to the osrm-routed HTTP API. You can see the new HTTP API here
https://github.com/Project-OSRM/osrm-backend/wiki/New-Server-api. We will
soon switch over the demoserver to this new API, likely beginning of April.
Below are the details:

- We will announce the exact date and time of the switchover 7 days in
advance in this issue and on this osrm-talk mailing list
- We will release a _release candidate_ before doing the switchover
- We will not release the final version of OSRM 5.0 before doing the
switchover
- If you want to test the new API now already, set it up yourself from this
branch https://github.com/Project-OSRM/osrm-backend/pull/1935
- We will not provide the old and new API at the same time, but do a hard
switchover of the demo server
- To be notified specifically when the change will happen, you can drop a
comment on this Github issue
https://github.com/Project-OSRM/osrm-backend/issues/2126

Comments are appreciated, either here or on the Github ticket
https://github.com/Project-OSRM/osrm-backend/issues/2126

Best,
Johan
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-fr] Fwd: Fwd: relations boundary admin_level=4 manquantes

[Philippe Verdy]

Le 22 mars 2016 à 01:41,  a écrit :

> Philippe, tu te fasis des amis en Allemagne avec tes relations gigognes :
> http://forum.openstreetmap.org/viewtopic.php?id=53173=7
>

Je ne vois pas de quoi tu parles sur ce fil.

En revanche le seul qui s'est "plaint" a dit quelquechose de carrément faux
(mensonge honteux de sa part), je cite "somebody changed the admin
boundaries of many islands from boundary=administrative to
boundary=land_area".

Eh non, je n'ai pas changé les frontières des ces "îles" mal tracées (qui
n'avaient et n'ont toujours que "natural=coastline" et sont toutes issues
d'un import automatique très grossier en basse résolution).

Elles n'ont JAMAIS été des "boundary=administrative" comme il le prétend
(les seules frontières de ce type étaient (et sont encore) les frontières
internationales (limites des eaux territoriales à 12 miles, toutes générées
par robot) qui sont toujours là!.

Je n'ai fait que le tri des éléments, pour grouper les milleirs d'iles et
ilots des différents atolls (tout en sachant que c'était approximatif) dans
des "land_area" qui pour l'instant sont séparés des frontières admins 8 qui
n'existaient pas non plus et n'ont jamais existé avant. Il y a vait une
ébauche de frontière 7 (pour la subdivision Tuamotu-Gambier) mais il
manquait plein de morceaux. Il n'y avait pas non plus de délimitation des
sous-archipels groupant les atolls (et donc leurs iles).

Je n'ai rien à me reprocher, en tout cas pas vis-à-vis de quelqu'un qui a
carrément menti sur ce forum (ou rien vérifié du tout pour savoir ce qui
pouvait être là avant)...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Overgrown (and illegal) bike track

[Nev Wedding]

It was mapped in 2009 and there appears nothing discernible on the satellite 
imagery and only one lone Strava track and no gps tracks near it, so if 
reverted to bush, I agree it’s time to delete it. 

> On 22 Mar 2016, at 7:39 PM, fors...@ozonline.com.au wrote:
> 
> Hi all
> 
> Just advising my intention to delete Way: 46916574 if there are no 
> objections. There are traces that a path existed at one time but its reverted 
> to bush. See the August 2015 archive for discussions on access=no
> 
> Tony
> 
> jpg photo, track bottom left to centre
> https://app.box.com/s/oove2z3kson43qabhud5yeixrkh88vtw
> 
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


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

Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na papire"?

[Pavel Machek]

Ahoj!

> 1) v terénu se vyskytuje rada "stezek", které ne/mají ráz "naucných stezek",
> nelze to od sebe rozlisit. Nektere zcela jiste naucne se tak nejmenuji 
> (nemaji v nazvu slovo "naucna" apod.) Vyrostlo jich jako houby po desti za 
> EU dotace, drtiva vetsina z nich NEMA ZNACENI a ma jen zastaveni (mapu trasy
> jen nekdy treba na prvnim zastveni) a rozhodne se mistne kryji. Ted jsem byl
> tusim u Drnovic (???) a kryla se tam nejaka mistni (obecni) "stezka" se 
> stezkou mikroregionu. Mam dojem ze podobnou vec jsem videl i v Brne u 
> Myslivny (je tam tusim Naucna stezkla lesnicka ale jeste i jina tabule jine 
> "stezky"). Presto ale ani jedna z nich nema v realu zadne znaceni.
> 
> 2) napr. "stezka" v obore Holedna (Brno)
> (http://openstreetmap.cz/#map=15/49.2009/16.5325=kK) ma ca 10 
> zastaveni, ale ty rozhodne nejsou usporadany za sebou linerane a kdo je chce
> vsechny projit, musi znat bud umisteni, nebo "mit mapu" (jako zde - mapa na 
> webu provozovatele(http://www.lesymb.cz/obj/278/obora_Holedna.jpg), na ktere
> dokonce ani neni trasovani na jedno zastaveni namalovane). V realu mapovana 
> neni - zadne znacky na stromech. Kdyz se ale podivame na nasi mapu, ve ktere
> je zaznacena (odkaz vyse), pak to pusobi vyhradne zmatecne - a) tolik 
> zelenych cest, ze vlastne nevim, kudy vede skutecna zelena KCT; b) v mape je
> trasa stezky zduraznena vzitou terenni "znackou" (bily ctverec + zeleny 
> sikmy pasek), takze to uzivatele navadi k hledani teto znacky v terenu
> 
> Tech zmapovatelnych stezek (naucnych, mistnich...) je mrak, je tedy nanejvys
> vhodne k tomu stanovit nejaky generalni postup a postoj, ale tak, aby to 
> nebylo v mape zmatecne vuci soucasnemu znaceni KCT. Tedy napr. jinou barvu 
> (svetlejsi/reflexni zelenou?). Pak povinne vsechna zastaveni (a ty pak 

Ja bych to mozna renderoval spis nejak min vyrazne... a urcite to nema mit 
"bily ctverec + zeleny sikmy pasek" pokud to neni znaceny v terenu.

Tmavsi zelena, carkovana? :-)

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

Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na papire"?

[vrs]

-- Původní zpráva --
Od: Petr Vozdecký 
Komu: OpenStreetMap Czech Republic 
Datum: 22. 3. 2016 7:40:39
Předmět: Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na 
papire"?

"
Ahoj,

diky za názory. K jednotlivým reakcím:

1) v terénu se vyskytuje rada "stezek", které ne/mají ráz "naucných stezek",
nelze to od sebe rozlisit. Nektere zcela jiste naucne se tak nejmenuji 
(nemaji v nazvu slovo "naucna" apod.) Vyrostlo jich jako houby po desti za 
EU dotace, drtiva vetsina z nich NEMA ZNACENI a ma jen zastaveni (mapu trasy
jen nekdy treba na prvnim zastveni) a rozhodne se mistne kryji. Ted jsem byl
tusim u Drnovic (???) a kryla se tam nejaka mistni (obecni) "stezka" se 
stezkou mikroregionu. Mam dojem ze podobnou vec jsem videl i v Brne u 
Myslivny (je tam tusim Naucna stezkla lesnicka ale jeste i jina tabule jine 
"stezky"). Presto ale ani jedna z nich nema v realu zadne znaceni.

2) napr. "stezka" v obore Holedna (Brno)
(http://openstreetmap.cz/#map=15/49.2009/16.5325=kK) ma ca 10 
zastaveni, ale ty rozhodne nejsou usporadany za sebou linerane a kdo je chce
vsechny projit, musi znat bud umisteni, nebo "mit mapu" (jako zde - mapa na 
webu provozovatele(http://www.lesymb.cz/obj/278/obora_Holedna.jpg), na ktere
dokonce ani neni trasovani na jedno zastaveni namalovane). V realu mapovana 
neni - zadne znacky na stromech. Kdyz se ale podivame na nasi mapu, ve ktere
je zaznacena (odkaz vyse), pak to pusobi vyhradne zmatecne - a) tolik 
zelenych cest, ze vlastne nevim, kudy vede skutecna zelena KCT; b) v mape je
trasa stezky zduraznena vzitou terenni "znackou" (bily ctverec + zeleny 
sikmy pasek), takze to uzivatele navadi k hledani teto znacky v terenu

"



Zdar, pokud neexistuje ani v terénu, ani na webu zřizovatele nic jako 
lineární trasa (ani s odbočkami), tak bych ty cedule dal do relace, ale 
neznačil jako type=route, ale použil nějaký jiný typ relace. V minulosti 
jsem tam dal type=site, i když to taky úplně přesně neodpovídá:



OSM: http://www.openstreetmap.org/relation/4427236

oficiální stránky: http://www.visitliberec.eu/liebiegove/?view=tab=1

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

Re: [OSM-talk-fr] QGIS/ArcGIS dans Openstreetmap

[Jean-Marc Liotier]

On 2016-03-22 09:53, moindjie mdahoma wrote:

> est il possible de superposer une couche deja numerisée dans qgis ou Arcgis 
> dans OSM? exemple j'ai deja numeriser les bati de mon village dans qgis et 
> arcgis et je vais l'importer dans openstreetmap, et je n'arrive pas, que dois 
> je faire alors?

Le plugin JOSM 'Opendata' est fait pour ça - une fois ce plugin installé
tu peux glisser-déplacer un fichier .shp dans JOSM et il y créera une
couche que tu peux éditer avant de la fusionner avec une couche de
données Openstreetmap (en prenant très grand soin de ne pas bousiller
des données déjà présentes) :
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData - attention aux
projections et à leur conversion éventuelle lors de l'ingestion par JOSM
! 

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

Re: [OSM-talk-fr] (sans objet)

[dHuy Pierre]

Bienvenue!De plus, as-tu regardé si tu pouvais trouver des imageries plus 
précises via des fond à licence ouverte? Attention le fond doit autoriser 
l'utilisation commercial :) 

Le Mardi 22 mars 2016 8h58, Jean-Marc Liotier  a écrit :
 

  On 03/22/2016 07:15 AM, moindjie mdahoma wrote:
  
  bonjours, je suis content de participer dans la liste et je peux contribuer 
sur les îles Comores là où je me trouve et j’espère aussi avoir votre aide pour 
que je puisse manipuler bien cet outil qui est nouveau et intéressant pour moi. 
 
 
 Bienvenue - n'hésites pas à exprimer remarques et questions !
 
 
   je constate que l'image aérienne qui se trouve sur openstreetmap est très 
ancienne et ne correspond pas vraiment à la realité actuelle sur terrain.  
 
 Oui, c'est souvent le cas - d'où l'importance cruciale du terrain. Mais 
l'imagerie aérienne est néanmoins très utile, ne serait-ce que pour positionner 
les observations du terrain.
 
 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na papire"?

[Miroslav Suchý]

Dne 22.3.2016 v 07:38 Petr Vozdecký napsal(a):
> , na ktere dokonce ani
> neni trasovani na jedno zastaveni namalovane). V realu mapovana neni -
> zadne znacky na stromech. Kdyz se ale podivame na nasi mapu, ve ktere je
> zaznacena (odkaz vyse), pak to pusobi vyhradne zmatecne - a) tolik
> zelenych cest, ze vlastne nevim, kudy vede skutecna zelena KCT; b) v

Což je akorát problem renderu. Třeba mapy.cz to renderují přehledně.


> mape je trasa stezky zduraznena vzitou terenni "znackou" (bily ctverec +
> zeleny sikmy pasek), takze to uzivatele navadi k hledani teto znacky v
> terenu

Souhlasím. Tohle může být problém. Asi by bylo fajn to vykreslovat jinou
značkou, které bychom dali význam (v reálu tam neni) nebo jenom jako
zvýrazněnou cestu bez symbolu.

Mirek

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

Re: [OSM-talk-ie] Oops, duplicate logain:refs added!

[Rory McCann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Colmn,

I don't use the location from logainm to match up to OSM objects.
Instead I use the hierachy. So if civil parish X is in barony Y in OSM
and logainm, and barony Y has a logainm:ref of 123, and logainm only
has one CP in barony Y with the name of "X", then we can match it up.

Also, at the moment, I've only match up counties, baronies, civil
parishes and townlands from logainm. I haven't let done any of the
other things like "population centres" or bridges.

Rory

On 21/03/16 15:32, Colm Moore wrote:
> Hi, I had noticed that some logainm locations are slightly 'rough'.
> While bridges and other point features would normally be within 100
> metres, other might be out quite a bit, e.g. Balrothery
> (Balbriggan, Dublin), which I moved by more than 1km (if I remember
> correctly). Might the moving of them have caused the duplicates? 
> Colm
> 
> --
- -
>
> 
Never doubt that a small group of thoughtful, committed citizens can
change the world. Indeed, it is the only thing that ever has. Margaret M
ead
>> 
>> Today's Topics:
>> 
>> 1. Oops, duplicate logain:refs added! (WAS: Re: Logainm data 
>> import #1 done!) (Rory McCann)
>> 
>> -
- -
>>
>>
>> 
From: Rory McCann 
>> Subject: [OSM-talk-ie] Oops, duplicate logain:refs added! (WAS:
>> Re: Logainm data import #1 done!)
>> 
>> Hi all,
>> 
>> It turns out there was a little problem with the logainm import,
>> which Meenatuggart noticed. There are about ~120 logainm:ref's
>> which are on more than one OSM object. Duplicate logainm:ref's
>> basically.
>> 
>> I've made a simple page on townlands.ie which shows the problems,
>> so that we can fix it up.
>> 
>> Please find the page here:
>> 
>> http://www.townlands.ie/progress/logainmqa/
>> 
>> I may add additional "QA" checks to that page when I can think
>> of additional ones.
>> 
>> R
>  ___ Talk-ie mailing
> list Talk-ie@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ie
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJW8QHkAAoJEOrWdmeZivv2cOoH/1EBL0q5l46iwhjktjHPCw5z
ojciqmnsW4D20Oo6ufC3jbtS/Xcj5mAIXW6azBEsTOlN1tKILH9y1NIrERK7c2iY
U/04UFCVtue6ia3Jc21Kymi+yUBuaXDrWoC60HzIIDfhLgzeUbuHnYp0iy+ch+tb
QiWxqrY1I80ntIJ1TnfI3tqwBedp/Ko4rBCGtkj1gHcEuH6CyDDRW2rFenZbeqHi
gYOtVbi4LMZw3juentmiOGujiUhuqy6IAAK6dGvcg5SZ4Jf6EWYZM0qeVVzp5x3T
pvCWysIxyss1ZGrLGiK+Bnt5gIVyrsD3FHET3jsntP4Y6YtH4Xs18v0IS62WPvo=
=XUgs
-END PGP SIGNATURE-

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

Re: [OSM-talk-fr] Fwd: Fwd: relations boundary admin_level=4 manquantes

[Philippe Verdy]

Je n'ai PAS fait grandir les communes, puisqu'elles n'étaient PAS là du
tout à l'origine (il n'y avait strictement aucune des communes de Polynésie
et d'ailleurs en dehors des Tuamotus les autres communes de Polynésie sont
toujours absentes : pour les iles de la Société, dont Tahiti, je vous mets
au défit de savoir à quel commune appartient un lieu avec les données
existantes, dès qu'on s'éloigne un peu du noeud central sur la même ile le
résultat est faux, et impossible de désambiuiser les homonymes !).

Non il n'y avait rien du tout, juste des noms de certains villages
(uniquemen leur noeud) et des noms pour certains motus ou iles hautes mais
même pas pour tous les 72 atolls des Tuamotus.

Et non un seul noeud ne suffit pas du tout, Nominatim lui-même situait les
aérodromes présents sur un des motus comme faisant partie d'un atoll
voisin, parce que justement il n'y avait AUCUN découpage (et Nominatim
cherchait alors parmi des noeuds proches)...

Je vois mal à quel titre les Allemands vont demander un revert (d'autant
que celui qui a fait cette demande s'est trompé à plusieurs reprises dans
ce qu'il a dit). A ce prix là ils peuvent demander un revert sur tous les
autres archipels environnants (et casser alors le travail commencé par
exemple en Indonésie ou aux Philippines, ou plus près aux Kiribati, aux
îles Marshall et aux îles Cook).

Franchement je ne comprend pas ta position.

Ces polygones n'ajoutent aucune ambiguité, au contraire ils éliminent
précisément pleins de possibilités en réduisant les recherches à un seul
atoll à la fois. Ces 72 atolls sont les briques de base de l'ISPF (pas les
communes puisqu'il y en a moins et que la plupart des communes ont
plusieurs atolls, eux-même regoupés souvent en communes associées au sein
de la cmême commune). Ensuite pour les noms de villages ou d'iles dans les
atolls, il y a de nombreux homonymes (en plus des noms alternatifs).

Sans ce découpage, on ne peut pas chercher facilement un lieu par son nom
et faire la différence selon l'atoll ou la commune d'appartenance, d'autant
plus qu'on n'a encore que très peu d'autres éléments de comparaison parmi
les autres toponymes géolocalisés les plus proches.

Que ce soit ensuite la commune ou la COM polynésienne qui soit compétente
sur le secteur maritime ne fait aucun différence, dans les deux cas elles
se réfèrent au même nom d'atoll. Et tout le modne s'en sert pour définir
aussi les limites des réserves naturelles, des zones de pêche ou des zones
ostréicoles, et s'y réfère aussi pour réglementer les lagons (presque tous
les atolls ont des lagons sauf 4 ou 5 qui sont comblés).

La plus grande partie de ce qui est à géolocaliser (d'autres toponymes)
sera sans ambiguité sur terre dans ces polygones précisément et on sait où
chercher, (il y a aussi des toponymes pour certaines zones marines ou pour
les passes, mais là aussi on sait où les chercher), chaque atoll étant déjà
là. Et je n'ai supprimé aucune des "iles" tracées avec les lignes de côtes
même si elles sont très peu précises. Les domaines maritimes et terrestres
sont déjà séparés, et j'ai rassemblé des tas d'iles oubliées (parmi les
milliers présentes) en les groupant atoll par atoll (et je crois n'en avoir
oublié aucune parmi celles qui étaient déjà là, même s'il en manque qui ne
sont pas tracées du tout). J'ai aussi éliminé des tracés qui n'étaient pas
des lignes de côte du tout mais des éléments au milieu de la terre (par
exemple des pistes d'aviation) et là c'était des erreurs manifestes.

Personne n'a pu me montrer où j'aurais pu faire une erreur d'attribution
(c'est possible mais avec les milliers de controles visuels et de
recherches faites, il ne doit pas en rester beaucoup (ce n'était pas du
tout le cas avant, c'était bourré d'erreurs ou de contradictions, mais
personne n'avait osé s'attaquer à faire le tri dans ce magma informe sur
une zone aussi étendue). Bref j'ai réduit le travail en le divisant en
sous-zones bien plus locales et plus faciles à traiter. Et même si les iles
sont redessinées et d'autres sont ajoutées ou fusionnées ou supprimées car
"fantômes", cela ne remet pas en cause l'existence et la séparation des
atolls.

En revanche il manque toujours les récifs émergés (les atolls noyés aussi
appelés "bancs", mais qui ne sont pas tous dans les eaux territoriales
tracées pour l'instant uniquement par génération automatique à 12 milles
 autour des iles existantes de ces atolls, à l'aide d'une ligne de base
tracée à "vue de nez" depuis de vielles images bing ou Yahoo en basse
résolution).

Le gros ennui est que pour avoir des limites plus précises, il faudrait du
monde sur place, et ces iles ont très peu d'habitants et localement pas
d'internet assez fiable, rapide et peu couteux pour que les locaux puissent
contribuer à OSM. On pourrait cependant s'appuyer sur le cadastre
polynésien pour améliorer les choses (mais on le sait aussi en métropole,
il n'est pas une référence pour délimiter la séparation entre terre et mer).

De plus on n'est pas 

Re: [OSM-talk-fr] (sans objet)

[Jean-Marc Liotier]

On 03/22/2016 07:15 AM, moindjie mdahoma wrote:
bonjours, je suis content de participer dans la liste et je peux 
contribuer sur les îles Comores là où je me trouve et j’espère aussi 
avoir votre aide pour que je puisse manipuler bien cet outil qui est 
nouveau et intéressant pour moi.


Bienvenue - n'hésites pas à exprimer remarques et questions !

 je constate que l'image aérienne qui se trouve sur openstreetmap est 
très ancienne et ne correspond pas vraiment à la realité actuelle sur 
terrain.


Oui, c'est souvent le cas - d'où l'importance cruciale du terrain. Mais 
l'imagerie aérienne est néanmoins très utile, ne serait-ce que pour 
positionner les observations du terrain.


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

Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na papire"?

[Petr Vozdecký]

Ahoj,

diky za názory. K jednotlivým reakcím:

1) v terénu se vyskytuje rada "stezek", které ne/mají ráz "naucných stezek",
nelze to od sebe rozlisit. Nektere zcela jiste naucne se tak nejmenuji 
(nemaji v nazvu slovo "naucna" apod.) Vyrostlo jich jako houby po desti za 
EU dotace, drtiva vetsina z nich NEMA ZNACENI a ma jen zastaveni (mapu trasy
jen nekdy treba na prvnim zastveni) a rozhodne se mistne kryji. Ted jsem byl
tusim u Drnovic (???) a kryla se tam nejaka mistni (obecni) "stezka" se 
stezkou mikroregionu. Mam dojem ze podobnou vec jsem videl i v Brne u 
Myslivny (je tam tusim Naucna stezkla lesnicka ale jeste i jina tabule jine 
"stezky"). Presto ale ani jedna z nich nema v realu zadne znaceni.

2) napr. "stezka" v obore Holedna (Brno)
(http://openstreetmap.cz/#map=15/49.2009/16.5325=kK) ma ca 10 
zastaveni, ale ty rozhodne nejsou usporadany za sebou linerane a kdo je chce
vsechny projit, musi znat bud umisteni, nebo "mit mapu" (jako zde - mapa na 
webu provozovatele(http://www.lesymb.cz/obj/278/obora_Holedna.jpg), na ktere
dokonce ani neni trasovani na jedno zastaveni namalovane). V realu mapovana 
neni - zadne znacky na stromech. Kdyz se ale podivame na nasi mapu, ve ktere
je zaznacena (odkaz vyse), pak to pusobi vyhradne zmatecne - a) tolik 
zelenych cest, ze vlastne nevim, kudy vede skutecna zelena KCT; b) v mape je
trasa stezky zduraznena vzitou terenni "znackou" (bily ctverec + zeleny 
sikmy pasek), takze to uzivatele navadi k hledani teto znacky v terenu

Tech zmapovatelnych stezek (naucnych, mistnich...) je mrak, je tedy nanejvys
vhodne k tomu stanovit nejaky generalni postup a postoj, ale tak, aby to 
nebylo v mape zmatecne vuci soucasnemu znaceni KCT. Tedy napr. jinou barvu 
(svetlejsi/reflexni zelenou?). Pak povinne vsechna zastaveni (a ty pak 
renderovat podobne jako rozcestniky) aby to davalo pri pohledu na mapu 
smysl. A pridavat tag osmc:symbol jen tam, kde je skutecne v realu pritomen.

A protoze jsme minimalne v Evrope i v tomto asi rarita, tak radeji 
renderovat vrstvu s NS jako option...

vop


-- Původní zpráva --
Od: Miroslav Suchy 
Komu: talk-cz@openstreetmap.org
Datum: 21. 3. 2016 9:26:34
Předmět: Re: [Talk-cz] Ne/mapovat stezky, ktere jsou znaceny jen "na 
papire"?

"Dne 20.3.2016 v 23:49 Petr Vozdecký napsal(a):
> 
> prosim o nazor: mapovat ci nemapovat (tedy vytvaret relaci s vysledkem 
zobrazeni trasy na mape) u tras (typicky naucna
> stezka), ktere maji v realu jen tabule s tematickymi zastavenimi, ale 
zadne fyzicke znaceni nemaji? Resp, jejich
> "spravnou trasu" (treba i nekontinualni s odbockami a variantnimi trasami 
k nelinearne umistenym tabulim) lze dohledat
> jinou cestou, napr. na souvisejicim webu...

1) ja osobne je znacim
2) v jinych (nez OSM mapach) to byva taky znacene
3) Ale hlavne to v realu byvaji fakt zajimave vylety a my je mame v rodine 
docela v oblibe a mapa s vyznacenou stezkou
byva dost casto jedine voditko "kudy dal".

> Znaceni s vysledkem vykreslovani v mape je dvojsecne - na jednu stranu 
muzeme rict, ze v mape nabizime "vice nez v
> realu", ale na druhou stranu v praxi existuje techto "naucnych stezek" 
mrak a nezridka se jejich trasy kryji - jak by to
> pak vypadalo na mape, sama zelena?

Vetsinou se kryji s KCT, ale NS s NS? Asi bys neco nasel, ale ja osobne o 
zadne nevim a nikdy me to v realu nezpusobilo
problem a to jsem jich uz navstivil dost.

Mirek

___
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-fr] (sans objet)

[moindjie mdahoma]

bonjours, je suis content de participer dans la liste et je peux contribuer sur 
les îles Comores là où je me trouve et j’espère aussi avoir votre aide pour que 
je puisse manipuler bien cet outil qui est nouveau et intéressant pour moi. je 
constate que l'image aérienne qui se trouve sur openstreetmap est très ancienne 
et ne correspond pas vraiment à la realité actuelle sur terrain.merci___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr