[Talk-si] "izboljšave" uporabnika 4KK

[Blaž Lorger]

Mogoče ste že opazili da je v zadnjih dneh uporabnik 4KK 
(https://www.openstreetmap.org/user/4KK) naredil več sprememb na 
področju Slovenije.

Kakšna je pozitivna, so pa tudi neustrezne.
Zgleda se je koncentriral na ceste pri tem pa je spremenil tudi precej 
relacij. Zaradi površnega dela so vsaj nekatere izmed teh relacij zdaj 
nepravilne. Kot na primer ta turn restriction 
(https://www.openstreetmap.org/relation/2653752/history). Zdaj je 
legalno narediti oster zavoj in se vrniti v krožišče.


Na moj poziv naj popravi take napake je jasno odgovoril da tega ne 
namerava storiti.

Predlagam da se lotite popravljanja.

Pozdrav,
  Blaž
___
Talk-si mailing list
Talk-si@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-si

Re: [Talk-si] divje in neustrezno spreminjanje klasifikacije poti

[Blaž Lorger]

In dalje kot bomo odlašali z revertanjem težje ga bo izvesti, ker 
nekateri že popravljajo posamezne napake:

https://www.openstreetmap.org/changeset/73235358#map=17/46.44110/15.08700
https://www.openstreetmap.org/changeset/73235726#map=13/46.4341/15.1010
...

On 10. 08. 19 21:08, Blaž Lorger wrote:


Preden sem včeraj poslal sporočilo v to mailing listo sem mu poslal 
sporočilo. Ni bilo odgovora, preprosto nadaljuje s "popravljanjem" karte.


Si pogledal zahodni del Pohorja? Vse gozdne ceste in traktorske vlake 
je preklasificiral kot običajne ceste. *Vse* spremembe klasifikacij 
cest so napačne. Če bo kdo skušal z avtom peljati po teh poteh bo 
neprijetno presenečen.


Problem je da preprosto spreminja obstoječe podatke. Dodal je bolj 
malo lastnih. Tam kjer jih je dodal pa so dodane ceste spojene z 
zgradbami, vegetacijo, mejami, ...
Zanima me ali imaš kak predlog kako popraviti zmešnjavo, ki jo je 
naredil, brez da bi preprosto revertal vse njegove spremembe. Ampak 
glede na to da ne reagira na sporočilo ne vidim druge možnosti.


Pozdrav
  Blaž

On 10. 08. 19 18:11, colored stone wrote:
Malce sem pogledal in gre verjetno za novejšega uporabnika, ki še ni 
dovolj dobro seznanjem s pravili urejanja. Niso čisto vse njegove 
poti popolnoma napačno klasificirane.


Primerno bi ga bilo prijazno opozoriti in ga napotiti na obstoječo 
dokumentacijo glede urejanja cest.


Po mojem še ni čas za kako revertanje.


Lep pozdrav,

Martin

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


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

Re: [Talk-si] divje in neustrezno spreminjanje klasifikacije poti

[Blaž Lorger]

Preden sem včeraj poslal sporočilo v to mailing listo sem mu poslal 
sporočilo. Ni bilo odgovora, preprosto nadaljuje s "popravljanjem" karte.


Si pogledal zahodni del Pohorja? Vse gozdne ceste in traktorske vlake je 
preklasificiral kot običajne ceste. *Vse* spremembe klasifikacij cest so 
napačne. Če bo kdo skušal z avtom peljati po teh poteh bo neprijetno 
presenečen.


Problem je da preprosto spreminja obstoječe podatke. Dodal je bolj malo 
lastnih. Tam kjer jih je dodal pa so dodane ceste spojene z zgradbami, 
vegetacijo, mejami, ...
Zanima me ali imaš kak predlog kako popraviti zmešnjavo, ki jo je 
naredil, brez da bi preprosto revertal vse njegove spremembe. Ampak 
glede na to da ne reagira na sporočilo ne vidim druge možnosti.


Pozdrav
  Blaž

On 10. 08. 19 18:11, colored stone wrote:
Malce sem pogledal in gre verjetno za novejšega uporabnika, ki še ni 
dovolj dobro seznanjem s pravili urejanja. Niso čisto vse njegove poti 
popolnoma napačno klasificirane.


Primerno bi ga bilo prijazno opozoriti in ga napotiti na obstoječo 
dokumentacijo glede urejanja cest.


Po mojem še ni čas za kako revertanje.


Lep pozdrav,

Martin

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

[Talk-si] divje in neustrezno spreminjanje klasifikacije poti

[Blaž Lorger]

Zdravo,

Ali kdo pozna tega (https://www.openstreetmap.org/user/kartog) "genija"?

Zgleda da je več ali manj naključno dvignil rang poti. Marsikje je 
traktorske vlake, ki niso prevozne niti s terenskimi vozili, 
klasificiral kot normalne ceste.


Mislim da bi bilo najbolje preprosto revertati vse njegove spremembe. 
Kolikor lahko ocenim je skoraj vse kar je naredil, verjetno kar vse kar 
je naredil, bilo spreminjanje klasifikacije poti.

Ima kdo izkušnje z masovnimi reverti?


Pozdrav
  Blaž


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

Re: [Talk-si] Poročilo srečanja Openstreetmap (Trnovski zvon, 31.3.2017)

[Blaž Lorger]

Pravzaprav je dosti večje odstopanje zaradi relativno redkega vzorčenja 
SRTM v primerjavi z LIDAR podatki. 90m proti 1 m. Večina (vsi) 
interpolacijskih algoritmov ima v dolinah (+) in na grebenih (-) zelo 
velika odstopanja. Če pogledaš kako cesto za katero veš da se enakomerno 
vzpenja boš na SRTM plastnicah dobil vtis kot da se v vsaki dolini 
precej dvigne na grebenu pa spusti, tudi po 100m. Če pogledaš plastnice 
generirane iz LIDAR podatkov lahko vidiš da je vzpon enakomeren.


Pozdrav,
  Blaž


On 30. 05. 2017 10:27, Stefan Baebler wrote:
Ja, ta teza bo kar držala, ker se vidi, da so odstopanja (radar 
izmeril višjo višino kot lidar) večja tam kjer je gozd, tam kjer ga ni 
(travniki) so pa sta višini reliefov precej bolj podobni.


lp,
Štefan

2017-05-29 22:05 GMT+02:00 Igor Brejc >:


SRTM višine so radarske, posnete iz Space Shuttla leta 2000. Do
napak (npr. pri Sedovcu) verjetno prihaja zato, ker je ta radar
meril odboj od dreves in ne od tal:


*Did the radar sample the tops of trees or the ground level?
*The radar does not "see" through thick vegetation canopies.
It probably penetrated a little way into some canopies, but in
general it followed near the top of the canopy.


https://www2.jpl.nasa.gov/srtm/faq.html


2017-05-29 21:11 GMT+02:00 Jaka Kranjc >:

On Sun, 28 May 2017 20:33:06 +0200
Marko Burjek > wrote:

> Pozdravljeni,
>
> Dne 27. maj 2017 21:15 je Jaka Kranjc > napisal/-a:
>
> > On Sat, 27 May 2017 17:46:12 +0200
> > Mitja Jež > wrote:
> >
> > > Pozdravljeni,
> > >
> > > On 03. 04. 2017 21:27, colored stone wrote:
> > > > Eno glavnih tem je "odprl" Klemen, ki je nekaj povedal o
> > > > orientacijskih kartah, ki se uporabljajo pri
orientacijskih
> > > > tekmah v okviru Orientacijske zveze Slovenije. Njegova
ideja
> > > > je, da bi poizkusili OSM uporabiti kot podlago za
izdelavo teh
> > > > kart. Nekaj podobnega je OPENORIENTEERINGMAP
> > > >
(http://oomap.co.uk/global/#/new/streeto_global/15/14.4876/46.0602/

> > > >
>).
> > >
> > > za planinska orientacijska tekmovanja rajše uporabljamo TOPO
> > > karte. Najverjetneje jih bom v te namene tiskal iz:
OpenTopoMap
> > > (https://opentopomap.org/#map=/15/46.0602/14.4876/
)
> > A niso malo prerevne napram DTK, sploh kar se tiče
simbologije?
> > Recimo jama vs jama z izvirom; pa vrtače nimajo minusa.
> >
> To se da popravit, ker je stil na GitHubu. Sam sem naredo
karto z
> OpenTopomap stilom in z slo LIDAR višinami in je kr opazna
razlika.
> Marsikje se bolj natančno vidi potek reliefa. Bom poskuso
dat del na
> net za primerjavo. Trenutno mam višine samo za okolico
Maribora na
> računalniku, ker jih je dosti.
Kjer so podatki že noter. POT-i pogosto potekajo v pregovornih
rovtah,
ki so seveda slabše skartirane. Ponekod tudi ni bila uvožena
raba tal.
V glavnem, precej dela.

PS, glede na tvojo primerjalno karto tudi sumim (pogosto
odstopa za
dve plastnici), da so na SRTM plastnicah GPS višine, ne naše,
kar še
poslabša stvari. Napaka ni vedno vidna, je pa pri Sedovcu (med
Ruško
in MB kočo), kjer je vrh nižji od višinskega pasu, kateremu
pripada.

LP



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




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





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


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

[Talk-si] nov maper razsaja po Sloveniji

[Blaž Lorger]

Izgleda da se je nek novinec (https://www.openstreetmap.org/user/Tanch) 
odločil da bo naredil par neumnosti.
V zadnjih nekaj dneh je naredil več sprememb v Sloveniji. Tista na 
Pohorju je bila totalna neumnost, zato sem jo odstranil. Preprosto je 
narisal pot, ki jo je prehodil, in vse skupaj označil kot en sam dolg 
footway, čeprav je vse že bilo mapirano


Predlagam da kdo pogleda še ostale spremembe, vsak področje, ki ga 
pozna. Dokler so sveže jih je mogoče enostavno odstraniti.


Pozdrav,
  Blaž

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

Re: [Talk-si] Vprašanje glede kategorizacije cest

[Blaž Lorger]

On Thursday 09 August 2012 12:08:48 Mark Martinec wrote:
  Pred kratkim sem začel urejati OSM in imam vprašanje glede kategorizacije
  cest. Iz legende je razvidno, da so tertiary road in tertiary link
  dvopasovne ceste s črto na sredini, ki loči vozna pasova.
  Vse manjše ceste pa so označene kot minor road.
  Moja težava izvira v tem, da je v okolici precej dobro vzdrževanih
  makadamskih poti za dostop do njiv s traktorjem, vendar pa se da po njih
  brez težav voziti z avtomobilom. Če pravilno razumem, potem makadamske
  poti tudi spadajo pod minor road, vendar mi ni všeč, da so označene
  enako kot širše asfaltirane ceste. Po drugi strani pa se mi vse možnosti
  pod Path zdijo premajhne, saj so primerljive z makadamskimi cestami po
  katerih se redno vozijo avtomobili.
  Kaj uporabljate vi?
 
 Za širše/boljše makadamske ceste predlagam:
   highway=unclassified
   surface=compacted
 
 za dobre kolovoze/gozdne/kmetijske ceste pa:
   highway=track
   tracktype=grade1

V redkih primerih so poljedelske/gozdne ceste celo asfaltirane. V takih 
primerih lahko uporabis:
   highway=track
   tracktype=grade1
   surface=paved
ali bolj specifično:
   highway=track
   tracktype=grade1
   surface=asphalt


Pri višjih razredih cest (tertiary, ...) je najbolje da se držiš tega 
priporočila http://wiki.openstreetmap.org/wiki/Sl:Map_Features

Bodi previden pri klasifikaciji gozdnih cest. Če boš grade spustil prehitro 
bodo skoraj vse gozdne ceste imele grade5. Najboljse da si za referenco vzameš 
kako višje rangirano cesto, ki ima kakšne odseke, ki niso najbolje utrjeni. 
Naprimer Lovrenc na Pohorju - Pesek ali Ribnica na Pohorju - Ribniška koča. To 
ti je referenca za grade1. Nekoliko slabše grade2, Še slabše a boljše od 
traktorskih vlak grade3. Traktorske vlake grade4. Komaj opazne poti grade5.

Pozdrav,
  BLaž


___
Talk-si mailing list
Talk-si@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-si

Re: [Talk-si] Portal s pešpotmi

[Blaž Lorger]

On Tuesday 29 May 2012 16:19:20 Damjan Gerl wrote:
 Martin Vuk, on 29/05/2012 15.36, wrote:
  Živijo,
  
  Geopedia je pripravila zanimiv portal
  http://www.pespoti.si
  
  A kaj ko je vse, kar oni počnejeo, licenčno nekompatibilno z
  openstreetmap :-(
  
  LP Martin
 
 Ja, nekaj podobnega je tukaj [0], potrebno pa bi bilo dodati še veliko
 pešpoti... (saj jih v Sloveniji skoraj ni označenih)
 Mimogrede pa bi bilo lepo tudi, če bi lahko kdo prevedel stran v
 slovenščino.
 

Očitno nisi prečital pravil uporabe (http://portal.geopedia.si/legal). Poglej 
točko 6. OSM in Geopedija sta nekompatibilna. Ne moreš vzeti podatkov iz enega 
in jih prenesti v drugega. Lahko pa svoje podatke vneseš v oba.

Mimogrede, če koga zanimajo peš poti v Sloveniji naj si pogleda 
http://wiki.openstreetmap.org/wiki/Sl:Slovenian_Hiking_Routes. Na tej strani 
sem zbral relacije, ki predstavljajo markirane peš poti.Pohorje, Kozjak in 
Peca so pokriti skoraj 100%, ostanek Slovenije pa bolj slabo.

Stran bi moral se nekoliko dopolniti. Manjka predvsem opis kako dodeljevati 
kategorijo poti. Do sedaj sem uporabljal pravilo:
 - lwn za gozdne učne poti in lokalne poti. Te so običajno markirane z rumeno 
zelenimi markacijami ali pa še to ne.
 - rwn za poti merkirane s Knafelčevo markacijo in regionalne obhodnice 
(Koroška planinska pot, Transferzala okoli Mute, ...).
 - nwn za daljše obhodnice. Kolikor vem se za to kvalificirata le slovenska 
planinska pot in Transferzala kurirjev in vezistov.
 - iwn za mednarodne poti (E6)

To se približno ujema s tem kar delajo avstrijci 
(http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Wanderwege).

Odseke planinskih poti sem poimenoval in oblikoval bolj po občutku.
Obstaja lista planinskih poti (http://www.pd-iskra-lj.si/poti.htm), ampak 
nisem siguren kako bi se uporaba tega vira ujemala z ODBL licenco.

Mogoče še opozorilo za tiste, ki nameravate označevati planinske poti v OSM. 
Geopedija in planinske karte so polni napak. Marsikje je potek poti na terenu 
bistveno drugacen kot je vrisan v teh virih.
Naprimer Pot kurirjev in vezistev od Male Kope do Slovenj Gradca 
http://hiking.lonvia.de/en/?zoom=15lat=46.50499lon=15.17151hill=0.57 in 
http://www.pespoti.si/pkv-tocka.php?id=53. To po svoje ni presenetljivo, saj 
je pot že v osnovi slabo označena, s sečnjo pa so v zadnjem času situacijo še 
poslabšali. Podrta debla z markacijami najteš tudi nekaj sto metrov od 
dejanske trase poti.

Pozdrav,
  Blaž

___
Talk-si mailing list
Talk-si@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-si

Re: [OSM-talk] Clarifying and representing road markings at junctions

[Blaž Lorger]

On Tuesday 29 September 2009 21:59:10 Matt Williams wrote:
 I've been noticing recently a problem we're going to/already have in
 our data when it comes to routing directions particularly. It concerns
 how to define continuations of roads at junctions and/or the road
 markings that delineate that. This problem manifests itself in many
 ways but for a first example, look at the attached image (road.png).
 
 On the left you will see the physical plan of a road junction near
 where I live. The way that it would be represented in the OSM data
 model is shown on the right. In this case, it would be sensible to
 make a way out of the segments 'a' and 'b' (yeah, I know we don't have
 segments any more, it's just an explanation tool), call it, e.g.
 'Curve Road' and make a second way out of segment 'c' and call it
 'Small Road'. At this stage, the date representation is sound and
 routing application would have no problem knowing how to parse it.
 However, there are two (increasingly common) ways in which this model
 will be forced to be broken:

I don't see where problem lies.

Is it that routing software will not be able to choose right route?
You never stated it clearly, but if I understand correctly road from segment a 
to b has right of way over segment c. So all you need is a way to indicate 
this. There are some proposals that could solve this (stop signs, yield, right 
of way).
If there are turn restrictions you can map those using turn restriction 
relation.
But if there is no explicit right of way and no turn restrictions it really 
should not matter how road markings are painted on the road. Routing software 
should be able to pick the right route based on other criteria (road 
classification, speed limits, traffic calming, ...).
Of course if roads b and c lead to completely different destinations (they 
don't join for several kilometers) it should be really easy to pick right way 
for specific destination.

The other problem could be that routing software will not be able to properly 
guide you through the junction.
If you take care that geometry of junction is represented correctly routing 
software will be able to guide you through the junction correctly. At least 
graphical representation should be correct.
Question is, will (voice) instructions be correct? I guess that in such 
situation clever navigation software would avoid using instruction 'go 
straight', but would rather use instructions 'keep left' or 'keep right'.

 Blaz

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

Re: [OSM-talk] Clarifying and representing road markings at junctions

[Blaž Lorger]

On Wednesday 30 September 2009 21:00:12 Martin Koppenhoefer wrote:
 2009/9/30 Blaž Lorger blaz.lor...@triera.net:
  I don't see where problem lies.
 
  Is it that routing software will not be able to choose right route?
  You never stated it clearly, but if I understand correctly road from
  segment a to b has right of way over segment c. So all you need is a way
  to indicate this. There are some proposals that could solve this (stop
  signs, yield, right of way).
  If there are turn restrictions you can map those using turn restriction
  relation.
  But if there is no explicit right of way and no turn restrictions it
  really should not matter how road markings are painted on the road.
  Routing software should be able to pick the right route based on other
  criteria (road classification, speed limits, traffic calming, ...).
 
 obviously you will find those road markings in situations, where there
 are some kind of restrictions or explicit right of way. The thing is
 less to _find_ the best way, but to give apropriate indications
 (follow the street to the right or something similar, at least not
 simply: turn right.
 
 see this for explanations:
 
 http://www.atzl.eu/stickerei/images/stories/stickerei/f03.jpg
 http://www.phipsl.de/fall1.jpg
 
 http://cdn.fotocommunity.com/photos/10510230.jpgimgrefurl=http://www.fotoc
 ommunity.de/pc/pc/display/10510230usg=__A3IpXoI79f0MoS-wOtdSQLUJz3E=h=100
 0w=659sz=225hl=destart=12um=1tbnid=gU2vwxzupwOUYM:tbnh=149tbnw=98p
 rev=/images%3Fq%3Dabknickende%2Bvorfahrt%26hl%3Dde%26client%3Dfirefox-a%26r
 ls%3Dcom.ubuntu:de:unofficial%26sa%3DN%26um%3D1

I was not able to open last one, but first two are cases where road with right 
of way is not the one going straight. By properly marking which way has right 
of way and making sure that junction geometry is correct, good navigation 
software should be able to produce sensible turn instructions without need for 
additional data.

 Blaz

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

Re: [OSM-talk] How to tag dead-ends and how to disting uish them from incomplete ways

[Blaž Lorger]

On Sunday 27 September 2009 02:38:31 Dave F. wrote:
 You see, this is where I get /really /confused
 
 I see no reference to 'todo' or 'continue' in the general OSM wiki.
 In the Groundtruth wiki page they're highlighted red, saying there there
 no reference page.
 
 I'm repeatedly told don't tag for the renderers
 
 Yet it appears in this case the renderers are telling the mappers what
 to do.
 The previous post implies these tags will only work in Groundtruth renders.
 
 What am I not understanding?
 
 At the moment it looks like the left hand is deliberately not
 telling the right what is going on.
 
 I fully support the endeavours of OSM but the hierarchical stature of it
 leaves me baffled at the moment.
 
 Oh,  Liz, if you're reading. please don't post to tell me some of the
 'regulars' have anarchy symbols on the blog page as if that some how
 makes it all OK.

It can hardly be called tagging for the renderer. No existing tag was misused 
to get desired result. Tagging schema and renderer style were extended to 
provide new functionality. That is what O in OSM stands for  :-)
Of course most/all renderers will support any tag. It is only a question of 
style used. I would not hold a breath while waiting for mainstream renderer 
setups to support way not finished tags, but you can always do it yourself.

Using todo tag is solution for existing problem and and a case study to see 
how it works out and whether is it useful. But you are right, making formal 
entry in wiki is overdue. I'll try to take some time to write a proposal.

  Blaz

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

Re: [OSM-talk] How to tag dead-ends and how to distinguish them from incomplete ways

[Blaž Lorger]

On Saturday 26 September 2009 20:09:34 Apollinaris Schoell wrote:
There are GroundTruth styles 
(http://wiki.openstreetmap.org/wiki/GroundTruth_Hiking_Map#IconTodoJunction) 
with support for tags todo=continue and todo=junction

In this sample 
(http://wiki.openstreetmap.org/wiki/Image:GroundTruth_Collage.png) nodes with 
tag todo=continue are represented as purple dots, while nodes with tag 
todo=junction are shown as purple x-es.

  But as I said, I'd much rather have a specific, rendered, more to do
  here tag for stubs that is removed when the way is extended.
 
 not a good idea for the normal map. have you ever seen any other commercial
 map with hey look this map is incomplete BS  info?
 sure it makes sense to get this info somehow into special maps for mappers.
 one option is to add it to garmin maps and you will see it when out there
  on survey. another option could be to add custom POI or use the  geocache
  features of a gps device.
 
  David
 
 
  ___
  talk mailing list
  talk@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk
 

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

Re: [OSM-talk] Garmin Streetpilot 2720

[Blaž Lorger]

Well, I don't know what kind of interface is used by your device but viewing 
and uploading maps to my GPSMap60 works very well with QLandkarte.

On Wednesday 16 September 2009 21:21:45 Stuckey wrote:
 Hello,
 
 I have a Garmin Streetpilot 2720 that I'd like to use with OSM. In
 trying to copy maps onto it I've followed the Wiki but haven't had
 much luck. I tried sendmap, but it gave me an error about not being
 able to find the GPS device.
 
 Does anyone know how I can import maps onto this device or where I
 might find useful information regarding the usage of this device under
 Linux?
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 

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

Re: [OSM-talk] VOTING for general highway-definition

[Blaž Lorger]

I've noticed that previous votes were changed to simple yes/no text. Should 
those votes be recast?

On Wednesday 16 September 2009 09:46:16 Martin Koppenhoefer wrote:
 The discussion seem to have calmed down, so please vote for
 highway-definition here:
 http://wiki.openstreetmap.org/wiki/Highway_key_voting_importance
 
 I suggest to not delete already given votes as they still represent
 voter's opinion, even if voting wasn't officially opened.
 
 cheers,
 Martin
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 

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

Re: [OSM-talk] JOSM display is squashed

[Blaž Lorger]

Use Mercator projection. But be careful. I think you have to use WGS84 for 
tracing over aerial imagery.

  Blaž

On Tuesday 15 September 2009 20:18:57 d f wrote:
 Hi
 
 I've downloaded some data to JOSM but the data is squashed in appearance in
  the north-south direction. It causes inaccuracies when I map. For instance
  i drew a rectangle at about 45 degrees, but when it showed in mapnik it
  looked like a parallelogram.
 
 I've downloaded the latest Java  JOSM.
 
 Any ideas for a solution?
 
 Cheers
 Dave F.
 

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

[Talk-si] uporaba QA orodij

[Blaž Lorger]

Zdravo,

Ali ste kaj uporabljali QA orodja 
(http://wiki.openstreetmap.org/wiki/Quality_Assurance)?
Mislim da bi bilo dobro če bi vsak malo pogledal področje, ki ga je mapiral. 
Kamorkoli v Sloveniji pogledaš najdeš precej napak. Začetni link za Slovenijo 
je 
http://keepright.ipax.at/report_map.php?db=osm_EUzoom=9lat=46.10223lon=14.91447.
 
To da na tej strani na svojem področju ne vidite napak še ne pomeni da jih ni. 
Orodje prikaže napake le na manjšem področju v centru karte, šele ko karto 
dovolj povečaš prikazane napake pokrijejo celo karto.

Izgleda da večina napak izhaja iz tega da manjkajo križišča. Marsikdo je karto 
risal tako da je vizualno OK, ni pa ustrezno spojil cest. Kratek obisk v 
wikiju ne bi škodil.Predvsem točka 5 na 
http://wiki.openstreetmap.org/wiki/Beginners_Guide_1.3.1.2

Obstajajo pa tudi kakšne bolj eksotične napake. Naprimer cesta, ki isto točko 
vsebuje kar petkrat :-S 
http://keepright.ipax.at/report_map.php?db=osm_EUzoom=15lat=46.04218lon=14.39283

Pozdrav,
  Blaž

___
Talk-si mailing list
Talk-si@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-si

Re: [Talk-si] Označevanje odsekov cest

[Blaž Lorger]

Lahko bi jih oznaceval ampak ne tako da zdruzis referenco in odsek. Namesto 
tega kar si predlagal:
ref=617-1054
bi raje uporabil locene tage:
ref=617
section=1054
Na ta nacin lahko v OSM shranis dodatno informacijo brez da povozis nacin kako 
so se ceste oznacevale do sedaj.

Mimogrede, to bi bilo dobro dodati med prdloge v wikiju. Pravzaprav je nekdo 
vceraj dodal predlog za section 
(http://wiki.openstreetmap.org/wiki/Proposed_Feature/Section). Stvar se nanasa 
na kose parkov, pokopalisc, naselij, ... Ampak mislim da bi predlog lahko 
razsiril tudi na odseke cest.


 Blaz

On Wednesday 19 August 2009 00:08:02 Damjan Gerli wrote:
 Torej, če sem prav razumel, odseke cest ne označujmo.

 LP
 Damjan

 PS: Na strani http://wiki.openstreetmap.org/wiki/Sl:Map_Features povezava
 na Uradni list:... ne deluje pravilno. Pravilna povezava je
 http://www.uradni-list.si/1/content?id=5835 , obstaja pa še sprememba
 http://www.uradni-list.si/1/content?id=46639

  -Izvirno sporočilo-
  Od: Stefan Baebler [mailto:stefan.baeb...@gmail.com]
  Poslano: 18. avgust 2009 23:46
  Za: Miha
  Kp: Damjan Gerli; talk-si@openstreetmap.org
  Zadeva: Re: [Talk-si] Označevanje odsekov cest
 
  V tabelo sem dodal fotografiji tablic za ilustracijo.
  http://wiki.openstreetmap.org/wiki/Sl:Map_Features#Poti_.28highway.29
 
  lp,
  Štefan
 
  2009/8/18 Miha miha.urban...@gmail.com:
   Jaz posameznih odsekov ne oznacujem, vpisem samo stevilko ceste,
   kategorizacijo, podlago (surface), source, kot je opisano na
   http://wiki.openstreetmap.org/index.php/Sl:Map_Features .
 
  Podatek o samem
 
   odseku pa je verjetno zanimiv bolj za cestna podjetja, kot
 
  za navigacijo oz.
 
   kartografijo.
  
   LP,
  
   Miha.
  
   2009/8/18 Damjan Gerli dam...@damjan.net
  
   Imam vprašanje glede označevanja odsekov cest. Ti so na
 
  terenu efektivno
 
   označeni in dolžina ceste, ki je označena za tablicah ob
 
  cesti, praktično
 
   začne z 0 pri novem odseku ceste. To sem opazil npr. na
 
  regionalni cesti R3
 
   št. 617 kjer sem opazil dva odseka 1054 in 1055 (manjše
 
  številke črne barve
 
   napisane zraven številke ceste, ki je na rumeni podlagi).
 
  Ali na osm te
 
   odseke označimo (in kako) ali jih izpustimo? Po moje bi
 
  bilo smiselno
 
   označevanje, ne vem pa kako. Ena varjanta bi lahko bila
 
  ref=617-1054.
 
   Damjan G.
  
  
  
   ___
   Talk-si mailing list
   Talk-si@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/talk-si
  
   --
   LP,
  
   Miha.
  
   ___
   Talk-si mailing list
   Talk-si@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/talk-si

 ___
 Talk-si mailing list
 Talk-si@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-si

___
Talk-si mailing list
Talk-si@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-si

Re: [OSM-talk] tag proposal surface=gravel; concrete; dirt; grass

[Blaž Lorger]

On Friday 14 August 2009 00:31:38 Martin Koppenhoefer wrote:
 2009/8/13 Sam Vekemans acrosscanadatra...@gmail.com:
  surface earth Probably the same as surface=ground
  should be change to the same as surface=dirt

 yes, clean up a little bit: dirt, mud, earth, ground seem all the same
 to me (I personally prefer ground).

  ... and it is NOT assumed surface=paved. .. we don't ASSUME :)  ..
  instead we have If no other values of surface is listed, the default
  value is surface=paved ... but actually, it should be
  surface=undefined, as the default value if none are listed.

 no, I think for roads we always had the default: paved and I would
 stick to this and tag the exceptions.

I usually tag paved road segment adjacent to unpaved road segment as paved. 
Otherwise it is all too easy to combine road segments without any warning from 
editor.


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

Re: [Talk-si] Državna kolesarksa mreža

[Blaž Lorger]

On Wednesday 29 July 2009 21:29:24 Miha wrote:
 Zivjo!

 Na OSM Wiki sem dodal navodila za označevanje državne kolesarske mreže
 http://wiki.openstreetmap.org/wiki/Slovenian_NCN_routes Komentarji
 dobrodošli (discussion page).

 Kot primer sem označil tudi del L 043, dela pa je še ogromno. Roka nisem
 postavil, ker je to malo bolj ambiciozen projekt kot pa PST ;-)

Ali kdo ve kako pravilno interpretirati listo kolesarsakih poti?
Problem je da je interaktivna karta premalo natančna da bi lahko identificiral 
podroben potek poti.
Po drugi strani nimam pojma kako identificirati lokalne ceste. Kaj pomenijo 
posamezne oznake: NC, JP 639440, LC 111450, R3 647/1173?
OK, za R3 je precej očitno da je regionalna cesta 3 reda. LC je verjetno 
lokalna cesta, JP mogoče javna pot? Je NC neoznačena/neklasificirana cesta?
Kaj pomenijo te cifre za JP in LC oziroma, ali je mogoče kje ugotoviti katero 
pot oziroma cesto referencira posamezna številka?

Oznake na terenu pa občasno izginejo. Naprimer za pot od Ruš do Maribora so na 
začetku prisotne oznake, zadnja je pri železniški postaji v Laznici, potem pa 
do Maribora brez oznak.

___
Talk-si mailing list
Talk-si@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-si

Re: [OSM-talk] tagging roads

[Blaž Lorger]

On Monday 03 August 2009 12:18:14 Emilie Laffray wrote:

  4. At the end it is always up to the individual mapper to decide what is
  narrow. While 1 meter is 1 meter.

 Yes, 1 meter is 1 meter. That's why using an approximation is actually
 worse than using a relative factor. Using a precise number is going to
 introduce errors that can be quite bad in the end. I strongly oppose any
 tags that is using a measurement that WILL NOT be accurate. Height is fine
 because it is defined. Relative parameters are more flexible.

We generally agree that there needs to be a way to assure quality of entered 
data. Using two distinct tags for measured and estimated values (width and 
est_width) is one possible approach. But in my opinion it is not the right 
approach:

a. You must be careful when entering the data to use appropriate tag. It is 
easier to use tag width in place of est_width. So most people will probably 
use width instead of est_width. In such dual tag approach using tag width for 
estimated width and measured_width for exact width is likely to give better 
results, since people that put more effort in gathering data are more likely to 
put more effort in entering such data in database.

b. But dual tag approach is also problematic for software that uses data. 
Either software has to use exact value with fallback to estimated value, or 
more likely, software will only use one value and ignore the other. This in 
turn will likely cause that mappers will use tag supported by software 
regardless if their data is accurate or not.

What I'm proposing is to add additional quality assurance tags. Absence of 
such tags would mean that there is no way to know how accurate data is. But 
presence of such tags would give reasonable assurance on data quality. I see 
need for two such tags: measurement method and date of data acquisition.
So, when road width is just roughly estimated mapper would add only tag width. 
When road width is actually measured, tagging would look like this:
   width=6.5
   width:method=tape
   width:date=2009-07-23
When width is measured on aerial photography method could be aerial and date 
would be date when photography was taken, ...

This approach can be used with all values that require measurement. It gives a 
way to quickly gather rough and inaccurate data with a way to identify 
inaccurate data, so it can be improved upon.



  5. Should definition of default road width ever change. All narrow=*
  tagging
  will be completely useless and will have to be reevaluated from scratch.
  Actually it will be useless before that due to subjective nature of value
  assigned to tag.

 Roads don't change width every day. Any change in the road will likely mean
 that it has been redone and therefore would probably need to be retagged if
 you want to be fully accurate in the first place.

  6. You will actually require large number of values for narrow to even
  approach granularity offered by one simple tag width. Either you will
  have to
  have narrow=no|foot|bicycle|motorcycle|car|suv|lgv|hgv|... Vale yes could
  not
  be used, since it does not specify how narrow the road is or it could be
  equivalent for narrow=car.

 I disagree. It is a relative parameter not to the vehicles but to the roads
 tag used. But in all honesty, it will only be applied on the smaller subset
 of the roads to be properly meaningful.

  7. You must prepare clear enough instructions how to select value for
  narrow,
  to reduce subjective factor to minimum.

 I believe that the subjective factor is no worse and actually better than
 using approximate width. It is something that is relative.

  8. You must get renderers to support it.

 Like everything else, like width..

  On the other hand, if you use tag width, which is already established tag
  if I
  may add, you have to accomplish following:
  1. You must get renderers to support it.
  2. Prepare some guidelines how to estimate road width. Of course using
  measuring equipment is always preferred but less realistic.
  3. Deprecate tag est_width and always store width data in tag width. Add
  additional tag that would state accuracy of width data. This is really
  not necessary, but will be easier to use by the software and probably
  also easier
  to map.

 This is ridiculous. I don't see how you can give guidelines to estimate
 road width. One of the problem with that is that in some areas the roads
 width will be fluctuating. In residential areas, it is common for streets
 to be changing.
 Deprecating est_width is a bit ridiculous. You are just saying in the end
 that width is estimated and therefore cannot be relied upon. Numbers and
 units are not something to be toyed with. The estimated factor clearly says
 it all. It is estimated. If you change this, width will not have a proper
 meaning as you will be mixing two qualities (estimated very broadly, and
 estimated ok).
 The relative factor of narrow is avoiding most of those issues since it is
 

[OSM-talk] tagging roads

[Blaž Lorger]

Hi,

I have noticed intense discussion about changing how roads should be tagged. 
It seems that some people devised their own way how to apply different values 
for highway tag and now attempt to force this on everybody.

On the other hand some people are attempting to introduce new values for 
highway tag 
(http://wiki.openstreetmap.org/wiki/Proposed_features/residential_narrow and 
http://wiki.openstreetmap.org/wiki/Proposed_features/residential_narrow/old).

Both approaches seem wrong. Changing how roads should be classified will break 
existing OSM data. Introducing new values will only add to confusion choosing 
road classification.

It seems that both issues are caused by desire to achieve certain rendering in 
mapnik or TAH. I guess best way to solve such problems would be to render 
streets differently based on value of tag width. This would encourage use of 
tag width. This way we would also gain useful data that can be used by routing 
software.

Another tag that is currently not supported by rendering engines is surface. I 
think renderers should make distinction between paved and unpaved roads. 
Otherwise you are risking that people will classify unpaved road as track just 
to achieve desired rendering effect. I am aware that highway=unsurfaced is 
rendered differently. But this value is supposed to be deprecated. Besides, 
unsurfaced roads can have different classifications 
(http://wiki.openstreetmap.org/wiki/Highway#Exceptions_to_physical_attributes).

I also propose extending instructions for road classification to use width tag 
when road is narrow. Instructions should also suggest what is considered 
narrow. For instance less than 4 meters for residential and unclassified roads, 
less than 6 meters for tertiary roads, less than 8 meters for secondary and 
primary roads. For trunks and motorways this limit should probably apply to 
lane width. Proposed limits on when certain type of road is considered narrow 
should match rendering rules.


 Blaž


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

Re: [OSM-talk] tagging roads

[Blaž Lorger]

On Sunday 02 August 2009 10:59:08 John Smith wrote:
 --- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote:
  I also propose extending instructions for road
  classification to use width tag

 I agree with everything else you wrote except width since I really don't
 want to get a tape measure out and measure widths of roads, using lanes=*
 to estimate widths would be more sensible and is already in use.

Unfortunately lanes only specifies number of lanes. In general every road that 
is not one way has at least 2 lanes, even if it is narrow, say 3.5 meters.

But you are right. Actually measuring road width is cumbersome and dangerous. 
We really don't want any OSM mapper to be nominated for Darwin award.  :-)

Still, you must get width data somehow. But, since width is more important in 
case of narrow road, you can limit gathering of width data only on narrow 
roads. Which has additional benefit that width for narrow road is easier to 
estimate than for wide road.
Obviously  it would be a good idea to add recommendation that only width of 
narrow roads should be estimated to tagging instructions. Some good practices 
on how to accurately estimate road width could also came handy.

Which leaves us with problem how accurate is width data. Wiki suggest using 
tag est_width. But this means that software needs to check two tags: width and 
est_width. Maybe additional tag (width_estimated=yes|no) could solve this 
problem. Default value for tag would be yes, since we can assume that someone 
that did not bother to acquire accurate data won't bother to add the tag to 
record such fact.


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

Re: [OSM-talk] tagging roads

[Blaž Lorger]

On Sunday 02 August 2009 11:49:06 Pieren wrote:
 On Sun, Aug 2, 2009 at 10:59 AM, John Smithdelta_foxt...@yahoo.com wrote:
  I agree with everything else you wrote except width since I really don't
  want to get a tape measure out and measure widths of roads, using lanes=*
  to estimate widths would be more sensible and is already in use.

 +1

 I prefere to add narrow=yes combined with residential or
 unclassified (or any other) highways. It should be interpreted as
 between 75% to 50% narrower than the default width of this highway
 type.

 Pieren

Wiki clearly states why tag narrow=yes would be a bad idea 
(http://wiki.openstreetmap.org/wiki/Key:width#Using_relative_sizes).
Basically, what is wide for bicycle is narrow for a car, what is wide for a 
car is narrow for a truck ...
Besides, I am not much bothered by narrow roads when driving a car. On the 
other hand some drivers will drive very slow when lane width drops under twice 
the width of their vehicle. Whose estimation of whether road is narrow or not 
is appropriate?

Specifying actual or at least estimated width is only way to ensure that data 
is universally usable. I guess heavy truck driver would not be amused when 
navigation system would direct him in 3m wide residential street, while car 
driver would only see it as a problem when passing another car.

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

Re: [OSM-talk] tagging roads

[Blaž Lorger]

On Sunday 02 August 2009 11:57:12 John Smith wrote:
 --- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote:
  Unfortunately lanes only specifies number of lanes. In
  general every road that
  is not one way has at least 2 lanes, even if it is narrow,
  say 3.5 meters.

 Even one way roads can have multiple lanes. Like dual carriage ways :)

  Some good practices
  on how to accurately estimate road width could also came
  handy.

 I feel you could get road widths accurately enough based simply on the
 number of lanes and the type of highway.

 For example, a residential road with 2 lanes, one in each direction is
 usually about 6-7m wide.

 Motorways are usually the numbers of lanes times 3m + 3m each side of the
 road way to allow for break downs, or maybe you could even have lanes=*
 breakdown_lanes=* to make this more accurate, but in any case a 3 lane
 motorway will be about 15m wide (3 * 3 + 3 + 3).

Main point here is to identify narrow roads. This is where road width matters 
the most. It is obvious that narrow roads will have 2 lanes. Unfortunately, 
those lanes will be narrow (2m or less). So number of lanes will in no way 
indicate road width, especially for narrow roads.


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

Re: [OSM-talk] tagging roads

[Blaž Lorger]

On Sunday 02 August 2009 12:36:48 Pieren wrote:
 On Sun, Aug 2, 2009 at 12:18 PM, Blaž Lorgerblaz.lor...@triera.net wrote:
  Wiki clearly states why tag narrow=yes would be a bad idea
  (http://wiki.openstreetmap.org/wiki/Key:width#Using_relative_sizes).
  Basically, what is wide for bicycle is narrow for a car, what is wide for
  a car is narrow for a truck ...

 The wiki says without clear definition about narrow. We just need a
 clear definition on the wiki and mine is a proposal. It is just
 proportional to the default width for all highway types for all
 countries. The advantage is that you don't have to tag all highways,
 just the ones you consider narrower.
 Otherwise, if you use the width=x , you have to do it on all roads or
 it will never be used by any application since they don't know if this
 segment is wider or narrower than the 95% of the highways where this
 width is missing.
 Here we could start again the discussion about the default width or
 default lanes and so on per highway type per country. That's the
 advantage of the key narrow, it is easy to use for mappers and it
 works for all countries.

Let's see:
1. There is no clear definition what is narrow.
2. There is no specification for default width of road type.
3. If narrow=yes is not applied everywhere where it should be it is equally 
useful/useless as with width tag.
4. At the end it is always up to the individual mapper to decide what is 
narrow. While 1 meter is 1 meter.
5. Should definition of default road width ever change. All narrow=* tagging 
will be completely useless and will have to be reevaluated from scratch. 
Actually it will be useless before that due to subjective nature of value 
assigned to tag.
6. You will actually require large number of values for narrow to even 
approach granularity offered by one simple tag width. Either you will have to 
have narrow=no|foot|bicycle|motorcycle|car|suv|lgv|hgv|... Vale yes could not 
be used, since it does not specify how narrow the road is or it could be 
equivalent for narrow=car.
7. You must prepare clear enough instructions how to select value for narrow, 
to reduce subjective factor to minimum.
8. You must get renderers to support it.

On the other hand, if you use tag width, which is already established tag if I 
may add, you have to accomplish following:
1. You must get renderers to support it.
2. Prepare some guidelines how to estimate road width. Of course using 
measuring equipment is always preferred but less realistic.
3. Deprecate tag est_width and always store width data in tag width. Add 
additional tag that would state accuracy of width data. This is really not 
necessary, but will be easier to use by the software and probably also easier 
to map.


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

Re: [OSM-talk] tagging roads

[Blaž Lorger]

On Sunday 02 August 2009 14:40:09 Pieren wrote:
 On Sun, Aug 2, 2009 at 1:39 PM, Blaž Lorgerblaz.lor...@triera.net wrote:
  Let's see:
  1. There is no clear definition what is narrow.
  2. There is no specification for default width of road type.
  3. If narrow=yes is not applied everywhere where it should be it is
  equally useful/useless as with width tag.

 Adding narrow=yes to your unclassified highway meaning it is 50% to
 75% narrower than the usual unclassified highway width in my country
 is universal and doesn't have to be added everywhere. When you add
 oneway=yes to a road, do you add oneway=no to all others ? When it is
 not attached, then it is the usual width of the unclassified highway
 in your country. And this can be used by any renderer who could draw
 thinner roads when the tag is present. But renderers will never draw
 the exact width=* of a road excepted at the very high zoom levels.

To my knowledge there is no such thing as usual highway width. There are 
certain standards for width of newly built roads, but those usually increase 
over time, which means you will be forced to periodically reevaluate *ALL* 
narrow tagging.
Obviously you haven't read my original message carefully. I suggested that 
only two widths are used by renderer and that border value is determined by 
renderer based on highway type.
Absence of width tag is interpreted as road having usual width. This is 
exactly same as absence of tag narrow.
Having actual road width is always more useful than having just some 
subjective estimate whether road is too narrow or not. Besides rendering you 
can use it to improve routing based on actual vehicle width/size.


  4. At the end it is always up to the individual mapper to decide what is
  narrow. While 1 meter is 1 meter.

 You always have some subjectivity when you map, look the other thread
 about residential vs unclassified. Below you say yourself it must be
 estimated, so your 1 meter can be 1.5 meters for someone else. Your
 just give the impression that a number is more accurate than an
 adjective but it is just an impression (excepted if you really measure
 the width with a tape).
Well yes, but with width it is only estimation error. While with narrow you 
must decide what is usual width for specific type of road, you make estimation 
error for road width, you make calculation error in percentage of usual road 
width and you must decide whether calculated percentage width is low enough to 
justify narrow=true.
some subjective factor is inevitable, but at least it should be kept as low as 
possible.
Besides in case of dispute or for whatever reason, road can actually be 
measured. Whether road is narrow or not is always matter of opinion, there is 
no way to improve accuracy here.

  6. You will actually require large number of values for narrow to even
  approach granularity offered by one simple tag width. Either you will
  have to have narrow=no|foot|bicycle|motorcycle|car|suv|lgv|hgv|... Vale
  yes could not be used, since it does not specify how narrow the road is
  or it could be equivalent for narrow=car.

 I only suggest narrow=yes. I don't understand what means
 narrow=foot|etc. It is narrower than the default width of the road. It
 has nothing to do with vehicules.
Again, what is default width of the road? And it has everything to do with 
vehicles, because what you need to now is whether your vehicle, which can be 
1, 2, 4 ... meters wide will be able to drive along road in question. 
Specifying narrow=yes|no can only be used to render a map. 



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

Re: [OSM-talk] Cathedral or chapel

[Blaž Lorger]

We certainly need better solution than JOSM presets historic=wayside_cross and 
historic=wayside_shrine. But with your suggestion there would be hundreds or 
even thousands values for tag place_of_worship.

Maybe we should just differentiate on size and build type: building hosting 
20+ people, building hosting 1-19 people, built structure but person can not 
enter (wayside_shrine), simple marker (wayside_cross, painted signs) and no 
markings (it is just holy place). I guess we also should not forget tents, 
wooden shacks, ...
Such places could also be areas.

Big buildings are not necessarily more holy than smaller structures or even 
unmarked places. So marking some big building (cathedral) should probably be 
considered in categories tourism and additional historic for older buildings.

On Monday 08 June 2009 16:46:55 Eugene Alvin Villar wrote:
 Tag suggestion:

 amenity=place_of_worship
 place_of_worship=parish chapel cathedral basilica church monastery convent
 retreat_house shrine abbey synagogue temple kingdom_hall jamaa masjid
 mosque pantheon etc.



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