date:20131021

We spreken over 'huisnummers' en 'brievenbussen'. Hetzelfde en toch
verschillend. Huisnummers worden gebruikt voor navigatie. Maar brievenbussen
hebben dan weer belang voor postbedeling, meer nog voor reclame, flyers,
enz.

Concreet kan het belangrijk zijn om te weten hoeveel brievenbussen er in een
bepaalde straat staan. Bijvoorbeeld verenigingen die flyers gaan rond
dragen, overlijdensberichten, reclamefolders. 

Nu vraag ik me af of  we het gebouw het nummer moeten toekennen bijv. 4 en
op aparte  nodes de brievenbus: 4/1, 4/2, enz.

 

 

Guy Vanvuchelen

 

Van: Marc Gemis [mailto:marc.ge...@gmail.com] 
Verzonden: maandag 21 oktober 2013 7:27
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] Newbie : Huis vatten

 

Moeten we misschien ook geen onderscheid maken tussen outdoor en indoor
navigatie ? Een bus nummer is niet belangrijk voor navigatie buiten, wel
voor binnen het gebouw.

Dan zouden we ook beter een andere tag gebruiken. Ik woonde vroeger op een
appartement, huisnr was 199 en had busnummer 2. Maar als er iemand op bezoek
kwam vermeldde we die bus 2 nooit, enkel de straatnaam en nummer 199.

Op veel adresformulieren staat bus ook op een aparte plek. Voor mij
allebei redenen om te denken aan addr:busnumber of zoiets.

 

Ik stel me bij dat hele huisnummer verhaal ook nog altijd een aantal vragen.
Het begint bij de keuzes die we maken: huisnnummers op gebouw en het gebruik
van associatedStreet, is dat wel de goede keuze voor de toekomst ? Hoe
passen POIs daarin ? Hoe kunnen we die huisnummers op gebnouwen verfijnen
als we busnummers en onderverdelingen in verdiepingen willen mappen ? Hoe
doet ze het in het buitenland  (want het is voorlopig nog steeds daar dat de
software geschreven wordt) ? Gaan we ons niet teveel isoleren ? 

 

Ik zal toch eens een aantal gevallen moeten bekijken in Brussel, Denemarken,
Duitsland, Frankrijk en Engeland. Proberen daarvan te leren.

 

Maar ja, ik zal wel een zagevent zijn :-)

 

groeten

 

m

 

 

2013/10/21 Marc Gemis marc.ge...@gmail.com

 

2013/10/20 Glenn Plas gl...@byte-consult.be

Maar zoals steeds mappen we niet voor de renderer :) 

 

Onlangs nog gelezen dat we feitelijk deze zin te pas en te onpas
gebruikebnkt. We mappen feitelijk wel voor de renderer, we mogen alleen niet
iets misbruiken om de renderer te misleiden. (alleen was het beter verwoord
dan wat ik nu schrijf zoek maar eens op in het archief v.d. tagging mailing
list.).

 

De punt-komma wordt altijd afgeraden in eender welke omstandigheid, omdat de
interpretatie ervan dubbelzinnig is. En het de verfijning van data
bemoeilijkt. Gesteld dat iemand later verdiepingen wil toevoegen aan de
individuele bus nummers, moet die dan ook punt-komma's gebruiken ?

 

Dus individuele punten is de beste manier.

 

groet

 

m

 

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

Re: [OSM-talk-be] Newbie : Huis vatten

Als je gewoon wil weten hoeveel brievenbussen er zijn, volstaat het om een
(en ik bedenk hier maar wat) number-of-flats=4 of zo op het gebouw te
plaatsen daarvoor heb je misschien die uitsplitsing misschien niet nodig.
Maar ik kan me ook  voorstellen dat het voor hulpdiensten handig is als men
zegt dat ze op appartement 2 op huisnummer 199 moeten zijn en dat ze via
(geavanceerde) navigatie tot aan de voordeur van het appartement (binnen in
het gebouw) geleid worden. Verre toekoemst ?

groeten

m


2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com

 We spreken over ‘huisnummers’ en ‘brievenbussen’. Hetzelfde en toch
 verschillend. Huisnummers worden gebruikt voor navigatie. Maar
 brievenbussen hebben dan weer belang voor postbedeling, meer nog voor
 reclame, flyers, enz.

 Concreet kan het belangrijk zijn om te weten hoeveel brievenbussen er in
 een bepaalde straat staan. Bijvoorbeeld verenigingen die flyers gaan rond
 dragen, overlijdensberichten, reclamefolders. 

 Nu vraag ik me af of  we het gebouw het nummer moeten toekennen bijv. 4 en
 op aparte  nodes de brievenbus: 4/1, 4/2, enz.

 ** **

 ** **

 Guy Vanvuchelen

 ** **

 *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
 *Verzonden:* maandag 21 oktober 2013 7:27

 *Aan:* OpenStreetMap Belgium
 *Onderwerp:* Re: [OSM-talk-be] Newbie : Huis vatten

 ** **

 Moeten we misschien ook geen onderscheid maken tussen outdoor en indoor
 navigatie ? Een bus nummer is niet belangrijk voor navigatie buiten, wel
 voor binnen het gebouw.

 Dan zouden we ook beter een andere tag gebruiken. Ik woonde vroeger op een
 appartement, huisnr was 199 en had busnummer 2. Maar als er iemand op
 bezoek kwam vermeldde we die bus 2 nooit, enkel de straatnaam en nummer
 199.

 Op veel adresformulieren staat bus ook op een aparte plek. Voor mij
 allebei redenen om te denken aan addr:busnumber of zoiets.

 ** **

 Ik stel me bij dat hele huisnummer verhaal ook nog altijd een aantal
 vragen. Het begint bij de keuzes die we maken: huisnnummers op gebouw en
 het gebruik van associatedStreet, is dat wel de goede keuze voor de
 toekomst ? Hoe passen POIs daarin ? Hoe kunnen we die huisnummers op
 gebnouwen verfijnen als we busnummers en onderverdelingen in verdiepingen
 willen mappen ? Hoe doet ze het in het buitenland  (want het is voorlopig
 nog steeds daar dat de software geschreven wordt) ? Gaan we ons niet teveel
 isoleren ? 

 ** **

 Ik zal toch eens een aantal gevallen moeten bekijken in Brussel,
 Denemarken, Duitsland, Frankrijk en Engeland. Proberen daarvan te leren.**
 **

 ** **

 Maar ja, ik zal wel een zagevent zijn :-)

 ** **

 groeten

 ** **

 m

 ** **

 ** **

 2013/10/21 Marc Gemis marc.ge...@gmail.com

 ** **

 2013/10/20 Glenn Plas gl...@byte-consult.be

 Maar zoals steeds mappen we niet voor de renderer :) 

 ** **

 Onlangs nog gelezen dat we feitelijk deze zin te pas en te onpas
 gebruikebnkt. We mappen feitelijk wel voor de renderer, we mogen alleen
 niet iets misbruiken om de renderer te misleiden. (alleen was het beter
 verwoord dan wat ik nu schrijf zoek maar eens op in het archief v.d.
 tagging mailing list.).

 ** **

 De punt-komma wordt altijd afgeraden in eender welke omstandigheid, omdat
 de interpretatie ervan dubbelzinnig is. En het de verfijning van data
 bemoeilijkt. Gesteld dat iemand later verdiepingen wil toevoegen aan de
 individuele bus nummers, moet die dan ook punt-komma's gebruiken ?

 ** **

 Dus individuele punten is de beste manier.

 ** **

 groet

 ** **

 m

 ** **

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


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

Re: [OSM-talk-be] Newbie : Huis vatten

2013-10-21 Thread Jo

Ik ben al redelijk wat aan het experimenteren geweest met huisnummers.

Met de tools die de JOSM plugin biedt, komen de nummers nogal gemakkelijk
op het gebouw terecht.

Hier zie je een voorbeeld van het gebruik van nodes aan de voordeur:

http://www.openstreetmap.org/#map=17/51.02572/4.73584

Wat ik daar handig aan vind, is dat zowel huisnummer als naam van
winkel/café gerenderd kunnen worden.

Anderzijds vind ik het wat lastig om te beslissen wat we aan de
associatedStreetrelaties toevoegen. De adresnodes, de gebouwen of alles?

Ondertussen heb ik me erbij neergelegd dat we op een 'hybride' manier
mappen.

Voor de simpele gevallen, meestvoorkomend: op het gebouw
Als er meerdere adressen, brievenbussen of entiteiten (bedrijven, winkels,
kantoren, diensten) in het gebouw zijn: aparte nodes

Ik ben er nog niet uit of ik het aanvaardbaar vind, om adresinformatie te
dupliceren. Twee zaken, in hetzelfde pand met hetzelfde adres. Eigenlijk
zouden we daar 2 nodes voor moeten maken en deze in de gebouwcontour
plaatsen. Het adres op de gebouwcontour. Het grote nadeel daarvan is dat je
een database met geografische mogelijkheden nodig hebt om dat te
interpreteren. Terwijl dat als je elke node van adresinformatie voorziet
(met de gemeenschappelijke tags in een AS-relatie), dan heb je genoeg aan
het XML-bestand met de gegevens.

Jo


Op 21 oktober 2013 08:32 schreef Marc Gemis marc.ge...@gmail.com:

 Als je gewoon wil weten hoeveel brievenbussen er zijn, volstaat het om een
 (en ik bedenk hier maar wat) number-of-flats=4 of zo op het gebouw te
 plaatsen daarvoor heb je misschien die uitsplitsing misschien niet nodig.
 Maar ik kan me ook  voorstellen dat het voor hulpdiensten handig is als
 men zegt dat ze op appartement 2 op huisnummer 199 moeten zijn en dat ze
 via (geavanceerde) navigatie tot aan de voordeur van het appartement
 (binnen in het gebouw) geleid worden. Verre toekoemst ?

 groeten

 m


 2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com

 We spreken over ‘huisnummers’ en ‘brievenbussen’. Hetzelfde en toch
 verschillend. Huisnummers worden gebruikt voor navigatie. Maar
 brievenbussen hebben dan weer belang voor postbedeling, meer nog voor
 reclame, flyers, enz.

 Concreet kan het belangrijk zijn om te weten hoeveel brievenbussen er in
 een bepaalde straat staan. Bijvoorbeeld verenigingen die flyers gaan rond
 dragen, overlijdensberichten, reclamefolders. 

 Nu vraag ik me af of  we het gebouw het nummer moeten toekennen bijv. 4
 en op aparte  nodes de brievenbus: 4/1, 4/2, enz.

 ** **

 ** **

 Guy Vanvuchelen

 ** **

 *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
 *Verzonden:* maandag 21 oktober 2013 7:27

 *Aan:* OpenStreetMap Belgium
 *Onderwerp:* Re: [OSM-talk-be] Newbie : Huis vatten

 ** **

 Moeten we misschien ook geen onderscheid maken tussen outdoor en indoor
 navigatie ? Een bus nummer is niet belangrijk voor navigatie buiten, wel
 voor binnen het gebouw.

 Dan zouden we ook beter een andere tag gebruiken. Ik woonde vroeger op
 een appartement, huisnr was 199 en had busnummer 2. Maar als er iemand op
 bezoek kwam vermeldde we die bus 2 nooit, enkel de straatnaam en nummer
 199.

 Op veel adresformulieren staat bus ook op een aparte plek. Voor mij
 allebei redenen om te denken aan addr:busnumber of zoiets.

 ** **

 Ik stel me bij dat hele huisnummer verhaal ook nog altijd een aantal
 vragen. Het begint bij de keuzes die we maken: huisnnummers op gebouw en
 het gebruik van associatedStreet, is dat wel de goede keuze voor de
 toekomst ? Hoe passen POIs daarin ? Hoe kunnen we die huisnummers op
 gebnouwen verfijnen als we busnummers en onderverdelingen in verdiepingen
 willen mappen ? Hoe doet ze het in het buitenland  (want het is voorlopig
 nog steeds daar dat de software geschreven wordt) ? Gaan we ons niet teveel
 isoleren ? 

 ** **

 Ik zal toch eens een aantal gevallen moeten bekijken in Brussel,
 Denemarken, Duitsland, Frankrijk en Engeland. Proberen daarvan te leren.*
 ***

 ** **

 Maar ja, ik zal wel een zagevent zijn :-)

 ** **

 groeten

 ** **

 m

 ** **

 ** **

 2013/10/21 Marc Gemis marc.ge...@gmail.com

 ** **

 2013/10/20 Glenn Plas gl...@byte-consult.be

 Maar zoals steeds mappen we niet voor de renderer :) 

 ** **

 Onlangs nog gelezen dat we feitelijk deze zin te pas en te onpas
 gebruikebnkt. We mappen feitelijk wel voor de renderer, we mogen alleen
 niet iets misbruiken om de renderer te misleiden. (alleen was het beter
 verwoord dan wat ik nu schrijf zoek maar eens op in het archief v.d.
 tagging mailing list.).

 ** **

 De punt-komma wordt altijd afgeraden in eender welke omstandigheid, omdat
 de interpretatie ervan dubbelzinnig is. En het de verfijning van data
 bemoeilijkt. Gesteld dat iemand later verdiepingen wil toevoegen aan de
 individuele bus nummers, moet die dan ook punt-komma's gebruiken ?

 ** **

 Dus individuele punten is de beste manier.

 ** **

 groet

 ** **

 m

Re: [OSM-talk-be] Newbie : Huis vatten

Onlangs nog gelezen dat we feitelijk deze zin te pas en te onpas
gebruikebnkt. We mappen feitelijk wel voor de renderer, we mogen
alleen niet iets misbruiken om de renderer te misleiden. (alleen
was het beter verwoord dan wat ik nu schrijf zoek maar eens op in
het archief v.d. tagging mailing list.).

Het was ook met enige ironie gesteld door mezelf.

die heb ik gemist zo vroeg op de ochtend :-)

Ja, vlak erna zei ik direct van dan toch maar te taggen , pro-renderer
dan. Kan gebeuren hee Marc :)

Dus individuele punten is de beste manier.

Ben ik mee akkoord, zoals ik al zei in de vorige post. In de
realiteit werken de search engines niet op ons
huisnummersysteem. Ik vind trouwens dat addr:bus geen slecht
idee is. Zo kan je addr:housenumber een echt nummer houden, dat
dan weer beter werkt op nominatim en co.

ik zie wel dat er problemen zijn met de search engines, maar jij hebt
er blijkbaar een beter zicht op. Wat loopt er allemaal mis met ons
huisnummersysteem ? Is er iets dat we kunnen doen om dat te verbeteren ?

Nominatim doet een letterlijke match, bv :
http://nm1.bitless.be/search.php?q=damstraat+100b4%2C+weerdeviewbox=4.48%2C50.97%2C4.5%2C50.96

Ik heb ook letterlijk 100b4 ingetypt in JOSM op die node. Let ook op op
de zoom level. Hij zet u wel ergens in de buurt maar echt inzoomen op
de node die het gevonden heeft doet die niet.

Neem nu het verschil met deze :
http://nm1.bitless.be/search.php?q=damstraat+102%2C+weerdeviewbox=4.45%2C50.95%2C4.47%2C50.94

Mooi ingezoomd. En je ziet mijn buren hun nummer direct. Dat is al 1
verschil tss addr:housenumber met of zonder alfanumerieke waardes.

Daarnaast is het nog voor de hand liggend dat intelligente searches niet
werken. Er is geen uniforme manier van busnummer aan te geven, onder
bus versta ik alles wat geen nummer is. Soms wordt dit gescheiden door
een streepje (-), een slash ( / ) of gewoon niets ( ). By example:
100 bus 4, 100b4, 100 b4, 100/b4 100-4, 100/4, 100 4, etc etc ...

Hoe ik het eigenlijk map is gewoon hoe het er staat, helaas is dit
beetje zoals geblinddoekt darts spelen. Je weet nooit hoe iemand zal
opzoeken. Probeer maar eens deze, gewoon spatie tss die nummer en bus :

http://nm1.bitless.be/search.php?q=damstraat+100+b4%2C+weerdeviewbox=4.46%2C50.98%2C4.48%2C50.97

Het is dus een kwestie van die info op een gestructureerde manier op te
slagen, bv in een addr:bus (geen number, want je kan ook 100a, 100 b
-deze is zelfs tricky door verwarring met busnr-, 100/c, 100-d terugvinden)

Ik vind huisnummers anders wel cool, sinds een goei jaarke werken eigen
nominatim imports beter op dat niveau, in 30% van mijn resultaten staat
er een huisnummer bij, voor reverse geocoding is dit natuurlijk veel
simpeler. (ik zoek de straatnaam/address van coordinaten), dan
rapporteer je gewoon de address gegevens die je terugvind (afkomstig van
node, relation, boundaries etc)

Gebrek aan uniformiteit is de eigenlijke oorzaak denk ik van dit probleem.

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

Re: [OSM-talk-be] Newbie : Huis vatten

Nog een probleem in verband met adressen en associatedStreet.

 

http://www.openstreetmap.org/?mlat=50.81842
http://www.openstreetmap.org/?mlat=50.81842mlon=4.88413#map=18/50.81842/4.
88413 mlon=4.88413#map=18/50.81842/4.88413

 

In Kumtich kom ik volgend probleem tegen: in de Druysstraat staat een huis
met huisnummer 25. Het adres van dat huis is: Bruulstraat 25.  Dat is een
erfenis uit het verleden toen er nog maar een stukje straat lag en dat werd
toen Bruulstraat genoemd omdat het er aan vast hing. Later werd de weg (als
verkaveling) doorgetrokken en kreeg de hele weg de naam Druysstraat.

Wat doen we in dit geval met de associatedStreet: ofwel een huis van de
Druysstraat in de associatedStreet 'Bruulstraat' zetten ofwel een huis met
adres 'Bruulstraat' in de associatedStreet 'Druysstraat', of het stukje
Druysstraat toch maar Bruulstraat noemen.

Dit is geen alleenstaand geval want er ligt ook nog een huis met adres
'Grijpenwegstraat 290' in de Molenbergweg.

Als er genavigeerd wordt op het huisnummer heb ik nog een probleem: de
ingang van een huis is alleen mogelijk via 'Medekersveld' terwijl het adres
'Leuvenselaan' is. Maar tussen de Leuvenselaan en het huis ligt een diepe
gracht met daarachter een hoge haag.

 

 

Guy Vanvuchelen

 

Van: Marc Gemis [mailto:marc.ge...@gmail.com] 
Verzonden: maandag 21 oktober 2013 9:48
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] Newbie : Huis vatten

 

 

 

2013/10/21 Glenn Plas gl...@byte-consult.be

On 2013-10-21 05:29, Marc Gemis wrote:

 

2013/10/20 Glenn Plas gl...@byte-consult.be

Maar zoals steeds mappen we niet voor de renderer :) 


Onlangs nog gelezen dat we feitelijk deze zin te pas en te onpas
gebruikebnkt. We mappen feitelijk wel voor de renderer, we mogen alleen niet
iets misbruiken om de renderer te misleiden. (alleen was het beter verwoord
dan wat ik nu schrijf zoek maar eens op in het archief v.d. tagging mailing
list.).

Het was ook met enige ironie gesteld door mezelf.

 

 

die heb ik gemist zo vroeg op de ochtend :-)

 

 

De punt-komma wordt altijd afgeraden in eender welke omstandigheid, omdat de
interpretatie ervan dubbelzinnig is. En het de verfijning van data
bemoeilijkt. Gesteld dat iemand later verdiepingen wil toevoegen aan de
individuele bus nummers, moet die dan ook punt-komma's gebruiken ?

Daar ben ik niet mee akkoord, in de wiki staat duidelijk omschreven wat een
punt-komma betekent.  Zie
http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
Interpretatie is dan toch eenduidig ?

 

 

Ok, dubbelzinnig is misschien een verkeerde woordkeuze. Maar zelfs op die
pagina raden ze aan om andere oplossingen te zoeken.

 

 

Dus individuele punten is de beste manier.

 

Ben ik mee akkoord, zoals ik al zei in de vorige post.  In de realiteit
werken de search engines niet op ons huisnummersysteem.   Ik vind trouwens
dat addr:bus geen slecht idee is.   Zo kan je addr:housenumber een echt
nummer houden, dat dan weer beter werkt op nominatim en co.

 

ik zie wel dat er problemen zijn met de search engines, maar jij hebt er
blijkbaar een beter zicht op. Wat loopt er allemaal mis met ons
huisnummersysteem ? Is er iets dat we kunnen doen om dat te verbeteren ?

 

m 

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

Re: [OSM-talk-be] Newbie : Huis vatten


Wat is het officiele adres ?  Los van wat de historiek is van dit huis ?

Een associatedStreet relatie is net gemaakt voor van die verre huizen 
toch te koppelen aan de straat.Volgens de uitleg van u denk ik dat 
de Druysstraat niet officieel is ?  Als dat zo is, verwijderen die 
handel en naar de realiteit zetten.


Glenn


On 2013-10-21 10:14, Guy Vanvuchelen wrote:


Nog een probleem in verband met adressen en associatedStreet.

http://www.openstreetmap.org/?mlat=50.81842mlon=4.88413#map=18/50.81842/4.88413

In Kumtich kom ik volgend probleem tegen: in de Druysstraat staat een 
huis met huisnummer 25. Het adres van dat huis is: Bruulstraat 25.  
Dat is een erfenis uit het verleden toen er nog maar een stukje straat 
lag en dat werd toen Bruulstraat genoemd omdat het er aan vast hing. 
Later werd de weg (als verkaveling) doorgetrokken en kreeg de hele weg 
de naam Druysstraat.


Wat doen we in dit geval met de associatedStreet: ofwel een huis van 
de Druysstraat in de associatedStreet 'Bruulstraat' zetten ofwel een 
huis met adres 'Bruulstraat' in de associatedStreet 'Druysstraat', of 
het stukje Druysstraat toch maar Bruulstraat noemen.


Dit is geen alleenstaand geval want er ligt ook nog een huis met adres 
'Grijpenwegstraat 290' in de Molenbergweg.


Als er genavigeerd wordt op het huisnummer heb ik nog een probleem: de 
ingang van een huis is alleen mogelijk via 'Medekersveld' terwijl het 
adres 'Leuvenselaan' is. Maar tussen de Leuvenselaan en het huis ligt 
een diepe gracht met daarachter een hoge haag.


Guy Vanvuchelen



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

Re: [OSM-talk-be] Newbie : Huis vatten

mijn oplossing is dat als de officiele naam Bruulstraat 25 is, het huis ook
in de associatedStreet Bruulstraat moet komen. Het speelt hierbij geen
rol of het stukje straat voor de deur anders noemt. Het stukje straat voor
de deur komt gewoon in de relatie met dezelfde naam als de straat, dus
Druysstraat.
Je krijgt dan misschien wel een warning in JOSM dat het huis te ver van de
straat afligt, maar die check houdt geen rekening met zulke uitzonderlijke
gevallen en dus kan je hem negeren in dit geval. Je zou hem enkel nog
moeten kunnen afzetten voor andere mappers.

Voor je probleem met navigatie is de enige oplossing dat we afstappen van
huisnummers op het gebouw te zetten, maar het Franse en Duitse systeem
overnemen om de huisnummer (bij benadering) op de deuringang te plaatsen.
Dit zijn net het soort problemen waarnaar ik wou verwijzen in een vorige
mail.



m


2013/10/21 Glenn Plas gl...@byte-consult.be

  Wat is het officiele adres ?  Los van wat de historiek is van dit huis ?

 Een associatedStreet relatie is net gemaakt voor van die verre huizen toch
 te koppelen aan de straat.Volgens de uitleg van u denk ik dat de
 Druysstraat niet officieel is ?  Als dat zo is, verwijderen die handel en
 naar de realiteit zetten.

 Glenn



 On 2013-10-21 10:14, Guy Vanvuchelen wrote:

  Nog een probleem in verband met adressen en associatedStreet.

 ** **


 http://www.openstreetmap.org/?mlat=50.81842mlon=4.88413#map=18/50.81842/4.88413
 

 ** **

 In Kumtich kom ik volgend probleem tegen: in de Druysstraat staat een huis
 met huisnummer 25. Het adres van dat huis is: Bruulstraat 25.  Dat is een
 erfenis uit het verleden toen er nog maar een stukje straat lag en dat werd
 toen Bruulstraat genoemd omdat het er aan vast hing. Later werd de weg (als
 verkaveling) doorgetrokken en kreeg de hele weg de naam Druysstraat.

 Wat doen we in dit geval met de associatedStreet: ofwel een huis van de
 Druysstraat in de associatedStreet ‘Bruulstraat’ zetten ofwel een huis met
 adres ‘Bruulstraat’ in de associatedStreet ‘Druysstraat’, of het stukje
 Druysstraat toch maar Bruulstraat noemen.

 Dit is geen alleenstaand geval want er ligt ook nog een huis met adres
 ‘Grijpenwegstraat 290’ in de Molenbergweg.

 Als er genavigeerd wordt op het huisnummer heb ik nog een probleem: de
 ingang van een huis is alleen mogelijk via ‘Medekersveld’ terwijl het adres
 ‘Leuvenselaan’ is. Maar tussen de Leuvenselaan en het huis ligt een diepe
 gracht met daarachter een hoge haag.

 ** **

 ** **

 Guy Vanvuchelen



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


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

Re: [OSM-talk-be] Newbie : Huis vatten

De realiteit is dat aan het begin en het einde een plaat staat met de naam
'Druysstraat' (ook op het stratenplan van Tienen). Omdat ik het verdacht
vond dat de nummering van 4 naar 25 sprong heb ik het adres op de brievenbus
genoteerd en dat blijkt: Bruulstraat 25 te zijn.

 

Guy Vanvuchelen

 

Van: Glenn Plas [mailto:gl...@byte-consult.be] 
Verzonden: maandag 21 oktober 2013 10:19
Aan: talk-be@openstreetmap.org
Onderwerp: Re: [OSM-talk-be] Newbie : Huis vatten

 

Wat is het officiele adres ?  Los van wat de historiek is van dit huis ?

Een associatedStreet relatie is net gemaakt voor van die verre huizen toch
te koppelen aan de straat.Volgens de uitleg van u denk ik dat de
Druysstraat niet officieel is ?  Als dat zo is, verwijderen die handel en
naar de realiteit zetten.

Glenn


On 2013-10-21 10:14, Guy Vanvuchelen wrote:

Nog een probleem in verband met adressen en associatedStreet.

 

http://www.openstreetmap.org/?mlat=50.81842
http://www.openstreetmap.org/?mlat=50.81842mlon=4.88413#map=18/50.81842/4.
88413 mlon=4.88413#map=18/50.81842/4.88413

 

In Kumtich kom ik volgend probleem tegen: in de Druysstraat staat een huis
met huisnummer 25. Het adres van dat huis is: Bruulstraat 25.  Dat is een
erfenis uit het verleden toen er nog maar een stukje straat lag en dat werd
toen Bruulstraat genoemd omdat het er aan vast hing. Later werd de weg (als
verkaveling) doorgetrokken en kreeg de hele weg de naam Druysstraat.

Wat doen we in dit geval met de associatedStreet: ofwel een huis van de
Druysstraat in de associatedStreet 'Bruulstraat' zetten ofwel een huis met
adres 'Bruulstraat' in de associatedStreet 'Druysstraat', of het stukje
Druysstraat toch maar Bruulstraat noemen.

Dit is geen alleenstaand geval want er ligt ook nog een huis met adres
'Grijpenwegstraat 290' in de Molenbergweg.

Als er genavigeerd wordt op het huisnummer heb ik nog een probleem: de
ingang van een huis is alleen mogelijk via 'Medekersveld' terwijl het adres
'Leuvenselaan' is. Maar tussen de Leuvenselaan en het huis ligt een diepe
gracht met daarachter een hoge haag.

 

 

Guy Vanvuchelen

 

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

Re: [OSM-talk-be] Newbie : Huis vatten

Prima.

Voor het laatste geval is zelfs de voordeur niet goed. Wel de ingang van de
oprit.

Ik zie het niet zitten om, voor de derde keer, alles nog maar eens te
wijzigen. Zo blijven we bezig. Wel vind ik het nuttig om in die speciale
gevallen een node op de juiste plaats te zetten. En dan maar hopen dat
niemand ze 'zomaar' wijzigt

 

Guy Vanvuchelen

 

Van: Marc Gemis [mailto:marc.ge...@gmail.com] 
Verzonden: maandag 21 oktober 2013 10:29
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] Newbie : Huis vatten

 

mijn oplossing is dat als de officiele naam Bruulstraat 25 is, het huis ook
in de associatedStreet Bruulstraat moet komen. Het speelt hierbij geen rol
of het stukje straat voor de deur anders noemt. Het stukje straat voor de
deur komt gewoon in de relatie met dezelfde naam als de straat, dus
Druysstraat.

Je krijgt dan misschien wel een warning in JOSM dat het huis te ver van de
straat afligt, maar die check houdt geen rekening met zulke uitzonderlijke
gevallen en dus kan je hem negeren in dit geval. Je zou hem enkel nog moeten
kunnen afzetten voor andere mappers.

 

Voor je probleem met navigatie is de enige oplossing dat we afstappen van
huisnummers op het gebouw te zetten, maar het Franse en Duitse systeem
overnemen om de huisnummer (bij benadering) op de deuringang te plaatsen.
Dit zijn net het soort problemen waarnaar ik wou verwijzen in een vorige
mail.

 

 

 

m

 

2013/10/21 Glenn Plas gl...@byte-consult.be

Wat is het officiele adres ?  Los van wat de historiek is van dit huis ?

Een associatedStreet relatie is net gemaakt voor van die verre huizen toch
te koppelen aan de straat.Volgens de uitleg van u denk ik dat de
Druysstraat niet officieel is ?  Als dat zo is, verwijderen die handel en
naar de realiteit zetten.

Glenn




On 2013-10-21 10:14, Guy Vanvuchelen wrote:

Nog een probleem in verband met adressen en associatedStreet.

 

http://www.openstreetmap.org/?mlat=50.81842
http://www.openstreetmap.org/?mlat=50.81842mlon=4.88413#map=18/50.81842/4.
88413 mlon=4.88413#map=18/50.81842/4.88413

 

In Kumtich kom ik volgend probleem tegen: in de Druysstraat staat een huis
met huisnummer 25. Het adres van dat huis is: Bruulstraat 25.  Dat is een
erfenis uit het verleden toen er nog maar een stukje straat lag en dat werd
toen Bruulstraat genoemd omdat het er aan vast hing. Later werd de weg (als
verkaveling) doorgetrokken en kreeg de hele weg de naam Druysstraat.

Wat doen we in dit geval met de associatedStreet: ofwel een huis van de
Druysstraat in de associatedStreet 'Bruulstraat' zetten ofwel een huis met
adres 'Bruulstraat' in de associatedStreet 'Druysstraat', of het stukje
Druysstraat toch maar Bruulstraat noemen.

Dit is geen alleenstaand geval want er ligt ook nog een huis met adres
'Grijpenwegstraat 290' in de Molenbergweg.

Als er genavigeerd wordt op het huisnummer heb ik nog een probleem: de
ingang van een huis is alleen mogelijk via 'Medekersveld' terwijl het adres
'Leuvenselaan' is. Maar tussen de Leuvenselaan en het huis ligt een diepe
gracht met daarachter een hoge haag.

 

 

Guy Vanvuchelen

 


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

 

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

Re: [OSM-talk-be] Newbie : Huis vatten

Je hebt gelijk dat we niet telkens van manier van taggen moeten veranderen.
Maar omdat we nu al behoorlijk wat ervaring krijgen met al dit soort
problemen, en we binnenkort met de import van Agiv data kunnen beginnen,
vind ik het belangrijk om de huidige manier van mappen te toetsen. Voldoet
ze wel ?
Ik vind het vreemd dat deze vragen niet meer aan bod zijn gekomen bij de
start van de Urbis import.

met vriendelijke groeten

m


2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com

 Prima.

 Voor het laatste geval is zelfs de voordeur niet goed. Wel de ingang van
 de oprit.

 Ik zie het niet zitten om, voor de derde keer, alles nog maar eens te
 wijzigen. Zo blijven we bezig. Wel vind ik het nuttig om in die speciale
 gevallen een node op de juiste plaats te zetten. En dan maar hopen dat
 niemand ze ‘zomaar’ wijzigt

 ** **

 Guy Vanvuchelen

 ** **

 *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
 *Verzonden:* maandag 21 oktober 2013 10:29

 *Aan:* OpenStreetMap Belgium
 *Onderwerp:* Re: [OSM-talk-be] Newbie : Huis vatten

 ** **

 mijn oplossing is dat als de officiele naam Bruulstraat 25 is, het huis
 ook in de associatedStreet Bruulstraat moet komen. Het speelt hierbij
 geen rol of het stukje straat voor de deur anders noemt. Het stukje straat
 voor de deur komt gewoon in de relatie met dezelfde naam als de straat, dus
 Druysstraat.

 Je krijgt dan misschien wel een warning in JOSM dat het huis te ver van de
 straat afligt, maar die check houdt geen rekening met zulke uitzonderlijke
 gevallen en dus kan je hem negeren in dit geval. Je zou hem enkel nog
 moeten kunnen afzetten voor andere mappers.

 ** **

 Voor je probleem met navigatie is de enige oplossing dat we afstappen van
 huisnummers op het gebouw te zetten, maar het Franse en Duitse systeem
 overnemen om de huisnummer (bij benadering) op de deuringang te plaatsen.
 Dit zijn net het soort problemen waarnaar ik wou verwijzen in een vorige
 mail.

 ** **

 ** **

 ** **

 m

 ** **

 2013/10/21 Glenn Plas gl...@byte-consult.be

 Wat is het officiele adres ?  Los van wat de historiek is van dit huis ?

 Een associatedStreet relatie is net gemaakt voor van die verre huizen toch
 te koppelen aan de straat.Volgens de uitleg van u denk ik dat de
 Druysstraat niet officieel is ?  Als dat zo is, verwijderen die handel en
 naar de realiteit zetten.

 Glenn




 On 2013-10-21 10:14, Guy Vanvuchelen wrote:

 Nog een probleem in verband met adressen en associatedStreet.

  


 http://www.openstreetmap.org/?mlat=50.81842mlon=4.88413#map=18/50.81842/4.88413
 

  

 In Kumtich kom ik volgend probleem tegen: in de Druysstraat staat een huis
 met huisnummer 25. Het adres van dat huis is: Bruulstraat 25.  Dat is een
 erfenis uit het verleden toen er nog maar een stukje straat lag en dat werd
 toen Bruulstraat genoemd omdat het er aan vast hing. Later werd de weg (als
 verkaveling) doorgetrokken en kreeg de hele weg de naam Druysstraat.

 Wat doen we in dit geval met de associatedStreet: ofwel een huis van de
 Druysstraat in de associatedStreet ‘Bruulstraat’ zetten ofwel een huis met
 adres ‘Bruulstraat’ in de associatedStreet ‘Druysstraat’, of het stukje
 Druysstraat toch maar Bruulstraat noemen.

 Dit is geen alleenstaand geval want er ligt ook nog een huis met adres
 ‘Grijpenwegstraat 290’ in de Molenbergweg.

 Als er genavigeerd wordt op het huisnummer heb ik nog een probleem: de
 ingang van een huis is alleen mogelijk via ‘Medekersveld’ terwijl het adres
 ‘Leuvenselaan’ is. Maar tussen de Leuvenselaan en het huis ligt een diepe
 gracht met daarachter een hoge haag.

  

  

 Guy Vanvuchelen

 ** **


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

 ** **

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


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

Re: [OSM-talk-be] Newbie : Huis vatten

Ik zou het laten staan zoals het is, als er een consensus komt is het 
kinderspel om dit via OverPass API op te lossen, al die notaties die ik 
daar opsomde, die kan je allemaal opvangen en uniform zetten via 
Overpass, hoe het ook uitdraait.  Kwestie van paar uurkes werk, en je 
heb heel belgie gedaan.  Net zoals Dexia -Belfius, met 500tal kantoren 
of zo, als je dat manueel gaat hernoemen    Dat was 5m werk via 
overpass, en nog eens 10m nakijken voor upload.


Dus doe vooral geen extra werk dat je toch zo kan opvangen.

On 2013-10-21 10:58, Marc Gemis wrote:
Je hebt gelijk dat we niet telkens van manier van taggen moeten 
veranderen. Maar omdat we nu al behoorlijk wat ervaring krijgen met al 
dit soort problemen, en we binnenkort met de import van Agiv data 
kunnen beginnen, vind ik het belangrijk om de huidige manier van 
mappen te toetsen. Voldoet ze wel ?
Ik vind het vreemd dat deze vragen niet meer aan bod zijn gekomen bij 
de start van de Urbis import.


met vriendelijke groeten

m


2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com 
mailto:guy.vanvuche...@gmail.com


Prima.

Voor het laatste geval is zelfs de voordeur niet goed. Wel de
ingang van de oprit.

Ik zie het niet zitten om, voor de derde keer, alles nog maar eens
te wijzigen. Zo blijven we bezig. Wel vind ik het nuttig om in die
speciale gevallen een node op de juiste plaats te zetten. En dan
maar hopen dat niemand ze 'zomaar' wijzigt




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

[OSM-talk-be] Uniformiteit van data (was Newbie: Huis vatten)

Glenn,

jij speelt toch graag met Overpass. We zouden misschien eens uniformiteit
moeten nastreven in winkelketens ook, bv Blokker, Kruidvat e.d. Daar zijn
nogal wat verschillende types shop aanwezig.

Ook heeft men mij eens aangeraden om benzine stations een brand, name, (en
waar mogelijk) een operator te geven. Dus ipv van enkel name=Shell, zou het
brand=Shell; name=Shell Berchem; operator=Jef Janssens moeten zijn. Het
stukje om alles brand te geven zou je kunnen automatiseren met via Overpass.

Zelfde probleem met brand vs name heb je bij banken, auto-dealers, etc.

m.


2013/10/21 Glenn Plas gl...@byte-consult.be

  Ik zou het laten staan zoals het is, als er een consensus komt is het
 kinderspel om dit via OverPass API op te lossen, al die notaties die ik
 daar opsomde, die kan je allemaal opvangen en uniform zetten via Overpass,
 hoe het ook uitdraait.  Kwestie van paar uurkes werk, en je heb heel belgie
 gedaan.  Net zoals Dexia -Belfius, met 500tal kantoren of zo, als je dat
 manueel gaat hernoemen    Dat was 5m werk via overpass, en nog eens 10m
 nakijken voor upload.

 Dus doe vooral geen extra werk dat je toch zo kan opvangen.

 On 2013-10-21 10:58, Marc Gemis wrote:

 Je hebt gelijk dat we niet telkens van manier van taggen moeten
 veranderen. Maar omdat we nu al behoorlijk wat ervaring krijgen met al dit
 soort problemen, en we binnenkort met de import van Agiv data kunnen
 beginnen, vind ik het belangrijk om de huidige manier van mappen te
 toetsen. Voldoet ze wel ?
 Ik vind het vreemd dat deze vragen niet meer aan bod zijn gekomen bij de
 start van de Urbis import.

  met vriendelijke groeten

  m


 2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com

  Prima.

 Voor het laatste geval is zelfs de voordeur niet goed. Wel de ingang van
 de oprit.

 Ik zie het niet zitten om, voor de derde keer, alles nog maar eens te
 wijzigen. Zo blijven we bezig. Wel vind ik het nuttig om in die speciale
 gevallen een node op de juiste plaats te zetten. En dan maar hopen dat
 niemand ze ‘zomaar’ wijzigt





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


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

Re: [OSM-talk-be] Newbie : Huis vatten

2013-10-21 Thread Jo

Net voor zulke uitzonderlijke gevallen vind ik dat de AS-relatie de
oplossing bij uitstek is.

Glenn, er is een groot verschil tussen huisnummer op gebouw en huisnummer
op voordeur/brievenbus/inrit en ik zie niet hoe je dat snel kunt omzetten
van het ene naar het andere met Overpass. Van node naar gebouw is
waarschijnlijk wel nog mogelijk.

Mijn voorkeur zou ook uitgaan naar aparte nodes voor de adressen. De
volgende vraag is dan: zetten we die gewoon ergens binnen de gebouwcontour?
Of zetten we die dan waar de voordeur is, met nog een extra entrance=main?
(Mijn voorkeur, veel eenvoudiger om te verwerken)

Bijkomende vraag is, zetten we dan zowel die nodes als de gebouwen in de
AS-relatie? Of enkel de adresnodes?

Die vragen zijn niet aan bod gekomen bij de UrbIS-import, omdat er toen
niemand was om ze te stellen. Ik zou 's terug moeten gaan kijken in de
archieven, of ik daar iets van vermeld had.

We hebben toen gewoon gekozen voor wat de meest gebruikelijke manier is om
adressen te mappen.

Bij huizen met 2 adressen (enorm veel hoekhuizen in Brussel), zijn er wel 2
nodes gebleven. Die staan in de contour. Ik zou ze liever als node op de
contour zien.

De UrbIS-import is ongeveer halfweg, het is nog niet te laat om daar van
taktiek te veranderen. Al zal het wel breder en nog 's in het Engels
besproken moeten worden.

Jo


Op 21 oktober 2013 11:25 schreef Glenn Plas gl...@byte-consult.be:

  Ik zou het laten staan zoals het is, als er een consensus komt is het
 kinderspel om dit via OverPass API op te lossen, al die notaties die ik
 daar opsomde, die kan je allemaal opvangen en uniform zetten via Overpass,
 hoe het ook uitdraait.  Kwestie van paar uurkes werk, en je heb heel belgie
 gedaan.  Net zoals Dexia -Belfius, met 500tal kantoren of zo, als je dat
 manueel gaat hernoemen    Dat was 5m werk via overpass, en nog eens 10m
 nakijken voor upload.

 Dus doe vooral geen extra werk dat je toch zo kan opvangen.

 On 2013-10-21 10:58, Marc Gemis wrote:

 Je hebt gelijk dat we niet telkens van manier van taggen moeten
 veranderen. Maar omdat we nu al behoorlijk wat ervaring krijgen met al dit
 soort problemen, en we binnenkort met de import van Agiv data kunnen
 beginnen, vind ik het belangrijk om de huidige manier van mappen te
 toetsen. Voldoet ze wel ?
 Ik vind het vreemd dat deze vragen niet meer aan bod zijn gekomen bij de
 start van de Urbis import.

  met vriendelijke groeten

  m


 2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com

  Prima.

 Voor het laatste geval is zelfs de voordeur niet goed. Wel de ingang van
 de oprit.

 Ik zie het niet zitten om, voor de derde keer, alles nog maar eens te
 wijzigen. Zo blijven we bezig. Wel vind ik het nuttig om in die speciale
 gevallen een node op de juiste plaats te zetten. En dan maar hopen dat
 niemand ze ‘zomaar’ wijzigt





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


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

Re: [OSM-talk-be] Newbie : Huis vatten

2013/10/21 Jo winfi...@gmail.com

 Mijn voorkeur zou ook uitgaan naar aparte nodes voor de adressen. De
 volgende vraag is dan: zetten we die gewoon ergens binnen de gebouwcontour?
 Of zetten we die dan waar de voordeur is, met nog een extra entrance=main?
 (Mijn voorkeur, veel eenvoudiger om te verwerken)


die entrace=main is optioneel zolang je geen survey ter plaatse hebt gedaan
vermoed ik ?

| Bijkomende vraag is, zetten we dan zowel die nodes als de gebouwen in de
AS-relatie? Of enkel de adresnodes?

Een AS-relatie laat dat (gebouw zonder nummer) niet toe dacht ik. Een
Street-relatie dan weer wel, maar daarvoor is er (bijna) geen support in
JOSM. (buiten manueel werk)
Een ander probleem dat ik soms heb met AS-relaties is dat je niet het huis
en een POI met dezelfde huisnummer kunt toevoegen zonder een duplicate
housenumber warning.

Even advocaat van de duivel spelen: :-)
Ik vraag me ook af wat je nu als voordeel van een AS-relatie ziet voor die
speciale gevallen. Een node met daarop huisnummer en straatnaam is even
duidelijk. En aangezien we dat al als compromis moeten doen...
Rest dan nog de meerwaarde van AS voor postcode en gemeente. Daar is het
feitelijk ook maar een lapmiddel voor het ontbreken van de gebieden met
postcodes en gemeentegrenzen.

Ik blijf voorlopig beiden mappen, en onderwijzen, maar de echte
meerwaarde ontgaat me als je toch ook het compromis hierboven toepast + de
naam op de straat zelf ook nog eens moet herhalen. Een zuivere AS-relatie
zou al die gegevens moeten bevatten, de straten dan enkel snelheid enz,
geen naam, een de huizen/nodes enkel de huisnummers. Als je het zo niet
doet is een AS-relatie een duplicaat van alles wat je op een ander ook
vindt.

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

Re: [OSM-talk-be] Newbie : Huis vatten

2013-10-21 Thread Jo

Je hebt daar natuurlijk wel gelijk in. Straatnaam op de ways zetten is
uiteraard historisch zo gekomen. Er waren eerst ways, dan relaties. Ik denk
niet dat we dat nu nog kunnen terugdraaien. Ook al zou het dan veel
zuiverder zijn.

addr:street op elk gebouw/adresnode, daar ben ik nooit voorstander van
geweest, maar als compromis zie ik het liever dan gemeente, postcode en
land ook nog 's te multipliceren.

Ach, wat redundantie helpt om aan validatie te doen. Dus zit ik er niet
mee. Alhoewel, binnenkort moet ik wellicht wel een purge doen (na zoeken
mbv filter), als ik data voor een groter gebied ga afhalen. M'n
computergeheugencapaciteit kan het tempo van de dataexplosie niet volgen...

Aan hosten van de data voor een bepaald gebied en zelf regelmatig wat
renderen, daar kan ik ook niet aan beginnen, omwille van enigszins
inefficiënt omgaan met opslagruimte. De AS-relatie helpt om dat toch een
beetje onder controle te houden.

Jo


Op 21 oktober 2013 12:27 schreef Marc Gemis marc.ge...@gmail.com:


 2013/10/21 Jo winfi...@gmail.com

 Mijn voorkeur zou ook uitgaan naar aparte nodes voor de adressen. De
 volgende vraag is dan: zetten we die gewoon ergens binnen de gebouwcontour?
 Of zetten we die dan waar de voordeur is, met nog een extra entrance=main?
 (Mijn voorkeur, veel eenvoudiger om te verwerken)


 die entrace=main is optioneel zolang je geen survey ter plaatse hebt
 gedaan vermoed ik ?

 | Bijkomende vraag is, zetten we dan zowel die nodes als de gebouwen in de
 AS-relatie? Of enkel de adresnodes?

 Een AS-relatie laat dat (gebouw zonder nummer) niet toe dacht ik. Een
 Street-relatie dan weer wel, maar daarvoor is er (bijna) geen support in
 JOSM. (buiten manueel werk)
 Een ander probleem dat ik soms heb met AS-relaties is dat je niet het huis
 en een POI met dezelfde huisnummer kunt toevoegen zonder een duplicate
 housenumber warning.

 Even advocaat van de duivel spelen: :-)
 Ik vraag me ook af wat je nu als voordeel van een AS-relatie ziet voor die
 speciale gevallen. Een node met daarop huisnummer en straatnaam is even
 duidelijk. En aangezien we dat al als compromis moeten doen...
 Rest dan nog de meerwaarde van AS voor postcode en gemeente. Daar is het
 feitelijk ook maar een lapmiddel voor het ontbreken van de gebieden met
 postcodes en gemeentegrenzen.

 Ik blijf voorlopig beiden mappen, en onderwijzen, maar de echte
 meerwaarde ontgaat me als je toch ook het compromis hierboven toepast + de
 naam op de straat zelf ook nog eens moet herhalen. Een zuivere AS-relatie
 zou al die gegevens moeten bevatten, de straten dan enkel snelheid enz,
 geen naam, een de huizen/nodes enkel de huisnummers. Als je het zo niet
 doet is een AS-relatie een duplicaat van alles wat je op een ander ook
 vindt.

 m.

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

Re: [OSM-talk-be] Uniformiteit van data (was Newbie: Huis vatten)


On 2013-10-21 11:43, Marc Gemis wrote:

Glenn,

jij speelt toch graag met Overpass. We zouden misschien eens 
uniformiteit moeten nastreven in winkelketens ook, bv Blokker, 
Kruidvat e.d. Daar zijn nogal wat verschillende types shop aanwezig.

Niet enkel shops, ook amenities ..



Ook heeft men mij eens aangeraden om benzine stations een brand, name, 
(en waar mogelijk) een operator te geven. Dus ipv van enkel 
name=Shell, zou het brand=Shell; name=Shell Berchem; operator=Jef 
Janssens moeten zijn. Het stukje om alles brand te geven zou je kunnen 
automatiseren met via Overpass.

Zo heb ik het voor mijn overbuur gedaan:

addr:city=Weerde
addr:country=BE
addr:housenumber=121
addr:postcode=1982
addr:street=Damstraat
amenity=fuel
brand=Octa+
fuel:1_25=yes
fuel:diesel=yes
fuel:octane_95=yes
fuel:octane_98=yes
operator=Sint-Martinus Garage
phone=+32 15 611511
source=survey

Op een node.  Zonder name,  operator is de fallback.

http://www.openstreetmap.org/browse/node/252793229

Glenn





Zelfde probleem met brand vs name heb je bij banken, auto-dealers, etc.

m.


2013/10/21 Glenn Plas gl...@byte-consult.be 
mailto:gl...@byte-consult.be


Ik zou het laten staan zoals het is, als er een consensus komt is
het kinderspel om dit via OverPass API op te lossen, al die
notaties die ik daar opsomde, die kan je allemaal opvangen en
uniform zetten via Overpass, hoe het ook uitdraait.  Kwestie van
paar uurkes werk, en je heb heel belgie gedaan. Net zoals Dexia
-Belfius, met 500tal kantoren of zo, als je dat manueel gaat
hernoemen    Dat was 5m werk via overpass, en nog eens 10m
nakijken voor upload.

Dus doe vooral geen extra werk dat je toch zo kan opvangen.

On 2013-10-21 10:58, Marc Gemis wrote:

Je hebt gelijk dat we niet telkens van manier van taggen moeten
veranderen. Maar omdat we nu al behoorlijk wat ervaring krijgen
met al dit soort problemen, en we binnenkort met de import van
Agiv data kunnen beginnen, vind ik het belangrijk om de huidige
manier van mappen te toetsen. Voldoet ze wel ?
Ik vind het vreemd dat deze vragen niet meer aan bod zijn gekomen
bij de start van de Urbis import.

met vriendelijke groeten

m


2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com
mailto:guy.vanvuche...@gmail.com

Prima.

Voor het laatste geval is zelfs de voordeur niet goed. Wel de
ingang van de oprit.

Ik zie het niet zitten om, voor de derde keer, alles nog maar
eens te wijzigen. Zo blijven we bezig. Wel vind ik het nuttig
om in die speciale gevallen een node op de juiste plaats te
zetten. En dan maar hopen dat niemand ze 'zomaar' wijzigt





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




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


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

Re: [OSM-talk-be] Newbie : Huis vatten


Het gaat over van dit :

addr:housenumber=100b4

dit makenL

addr:housenumber=100
addr:bus=4

Hypotetisch gesteld.  Dat levert geen problemen op, een node blijft een 
node, een way blijft een way.


Glenn


On 2013-10-21 12:08, Jo wrote:
Net voor zulke uitzonderlijke gevallen vind ik dat de AS-relatie de 
oplossing bij uitstek is.


Glenn, er is een groot verschil tussen huisnummer op gebouw en 
huisnummer op voordeur/brievenbus/inrit en ik zie niet hoe je dat snel 
kunt omzetten van het ene naar het andere met Overpass. Van node naar 
gebouw is waarschijnlijk wel nog mogelijk.


Mijn voorkeur zou ook uitgaan naar aparte nodes voor de adressen. De 
volgende vraag is dan: zetten we die gewoon ergens binnen de 
gebouwcontour? Of zetten we die dan waar de voordeur is, met nog een 
extra entrance=main? (Mijn voorkeur, veel eenvoudiger om te verwerken)


Bijkomende vraag is, zetten we dan zowel die nodes als de gebouwen in 
de AS-relatie? Of enkel de adresnodes?


Die vragen zijn niet aan bod gekomen bij de UrbIS-import, omdat er 
toen niemand was om ze te stellen. Ik zou 's terug moeten gaan kijken 
in de archieven, of ik daar iets van vermeld had.


We hebben toen gewoon gekozen voor wat de meest gebruikelijke manier 
is om adressen te mappen.


Bij huizen met 2 adressen (enorm veel hoekhuizen in Brussel), zijn er 
wel 2 nodes gebleven. Die staan in de contour. Ik zou ze liever als 
node op de contour zien.


De UrbIS-import is ongeveer halfweg, het is nog niet te laat om daar 
van taktiek te veranderen. Al zal het wel breder en nog 's in het 
Engels besproken moeten worden.


Jo


Op 21 oktober 2013 11:25 schreef Glenn Plas gl...@byte-consult.be 
mailto:gl...@byte-consult.be:


Ik zou het laten staan zoals het is, als er een consensus komt is
het kinderspel om dit via OverPass API op te lossen, al die
notaties die ik daar opsomde, die kan je allemaal opvangen en
uniform zetten via Overpass, hoe het ook uitdraait.  Kwestie van
paar uurkes werk, en je heb heel belgie gedaan.  Net zoals Dexia
-Belfius, met 500tal kantoren of zo, als je dat manueel gaat
hernoemen    Dat was 5m werk via overpass, en nog eens 10m
nakijken voor upload.

Dus doe vooral geen extra werk dat je toch zo kan opvangen.

On 2013-10-21 10:58, Marc Gemis wrote:

Je hebt gelijk dat we niet telkens van manier van taggen moeten
veranderen. Maar omdat we nu al behoorlijk wat ervaring krijgen
met al dit soort problemen, en we binnenkort met de import van
Agiv data kunnen beginnen, vind ik het belangrijk om de huidige
manier van mappen te toetsen. Voldoet ze wel ?
Ik vind het vreemd dat deze vragen niet meer aan bod zijn gekomen
bij de start van de Urbis import.

met vriendelijke groeten

m


2013/10/21 Guy Vanvuchelen guy.vanvuche...@gmail.com
mailto:guy.vanvuche...@gmail.com

Prima.

Voor het laatste geval is zelfs de voordeur niet goed. Wel de
ingang van de oprit.

Ik zie het niet zitten om, voor de derde keer, alles nog maar
eens te wijzigen. Zo blijven we bezig. Wel vind ik het nuttig
om in die speciale gevallen een node op de juiste plaats te
zetten. En dan maar hopen dat niemand ze 'zomaar' wijzigt





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




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


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

Re: [OSM-talk-be] Uniformiteit van data (was Newbie: Huis vatten)


 addr:city=Weerde
 addr:country=BE
 addr:housenumber=121
 addr:postcode=1982
 addr:street=Damstraat
 amenity=fuel
 brand=Octa+
 fuel:1_25=yes
 fuel:diesel=yes
 fuel:octane_95=yes
 fuel:octane_98=yes
 operator=Sint-Martinus Garage
 phone=+32 15 611511
 source=survey




ziet er goed uit. Sommigen zullen dan wel weer zeggen dat de operator
feitelijk de name is, maar ja. Je kan toch nooit goed doen voor iedereen :-)
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Uniformiteit van data (was Newbie: Huis vatten)

Zijn ook 2 dingen, gebouw, een garage met een benzinepomp voor.  Ik heb 
dit jaren geleden zo getagt, en jij zegt vandaag nog hetzelfde (operator 
en brand) dus denk dat we nog goed zitten :)


On 2013-10-21 13:02, Marc Gemis wrote:



addr:city=Weerde
addr:country=BE
addr:housenumber=121
addr:postcode=1982
addr:street=Damstraat
amenity=fuel
brand=Octa+
fuel:1_25=yes
fuel:diesel=yes
fuel:octane_95=yes
fuel:octane_98=yes
operator=Sint-Martinus Garage
phone=+32 15 611511 tel:%2B32%2015%20611511
source=survey




ziet er goed uit. Sommigen zullen dan wel weer zeggen dat de operator 
feitelijk de name is, maar ja. Je kan toch nooit goed doen voor 
iedereen :-)




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


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

[OSM-talk-be] Newbie : Huis vatten - adressen - UrbIS

2013-10-21 Thread Pierre Parmentier

Je reviens sur le message de Jo et sur la situation avec l'import UrbIS.

Nous avons différentes situations :

   1. contour (way) avec une adresse unique (c'est à dire un numéro) :
   l'adresse est sur le contour (way)
   2. contour (way) avec plusieurs adresses dans l'import : plusieurs nodes
   qui ont chacun une adresse qui est sur les nodes et les nodes sont à
   l'intérieur du way
   3. building à l'angle de deux rues avec dans l'import plusieurs numéros
   sur des nodes : un ou plusieurs numéro + adresse dans chaque rue ;
voir Proposed
   Features/Multiple
addresseshttp://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses,
   avec, par exemple *addr:1*:street=Foo Street, *addr:1*:housenumber=1, *
   addr:2*:street=Bar Road, *addr:2*:housenumber=5. Les nodes sont aussi à
   l'intérieur du way.
   4. building à l'angle de deux rues avec lors de l'import un seul numéro
   sur le contour mais sur le terrain (in situ) on observe des adresses dans
   les deux rues : le schéma ci-dessus reste applicable (numéro et adresse sur
   le way).

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

Re: [OSM-talk-be] Newbie : Huis vatten - adressen - UrbIS

2013/10/21 Pierre Parmentier pierrecparment...@gmail.com

 Proposed Features/Multiple 
 addresseshttp://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses



I don't like this proposal too much. This is a relation in disguise. So why
not use a real relation instead ? A building relation (which already
exists) with multiple address node members.  -- I know it's not your
proposal, so I won't shoot the messenger :-)
This is a mess to maintain if you have to manually make sure that all
numbers behind a addr: are there. I would vote against it.

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

Re: [OSM-talk-be] Newbie : Huis vatten - adressen - UrbIS

And I'm not the only one: see
http://wiki.openstreetmap.org/wiki/Talk:Proposed_Features/Multiple_addresses
none of the comments was in favor of this proposal.


On Mon, Oct 21, 2013 at 2:38 PM, Marc Gemis marc.ge...@gmail.com wrote:


 2013/10/21 Pierre Parmentier pierrecparment...@gmail.com

 Proposed Features/Multiple 
 addresseshttp://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses



 I don't like this proposal too much. This is a relation in disguise. So
 why not use a real relation instead ? A building relation (which already
 exists) with multiple address node members.  -- I know it's not your
 proposal, so I won't shoot the messenger :-)
 This is a mess to maintain if you have to manually make sure that all
 numbers behind a addr: are there. I would vote against it.

 m.

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

Re: [OSM-talk-be] Newbie : Huis vatten - adressen - UrbIS

We should stick to the current well known scheme, thinking about this 
renderer issue... it makes no sense to manoevre around a faulty 
renderer, being it nominatim or a tileserver.  If a search for a street 
+ housenumber,  city returns nothing, but a search for that same street, 
city without the number does return fine, who's fault is that?  Search 
engines are suppose to be 'best effort' .  The correct behavior should 
be to drop the housenumber from the search parameters (no exact match is 
found), and then lower the resolution of the result set to encompass the 
street (visually).  In nominatim that would translate to bunch of hits  
when searching for an address, when reverse searching for a coordinate 
that would just return : streetname , postalcode, city, country  no 
housenumber.


That proposal ,I mentioned that in a earlier comment already,  (to be 
aware of it's existance) but it's flawed as you noticed.  Also, there 
are 203 occurences in the whole database like this:


http://taginfo.openstreetmap.org/keys/addr%3A1%3Ahousenumber

Safe to say, it would be a lost effort following this scheme.  But also, 
we would be the only ones using it imho   We should just keep 
tagging the karlsruhe way.


Glenn

On 2013-10-21 14:40, Marc Gemis wrote:
And I'm not the only one: see 
http://wiki.openstreetmap.org/wiki/Talk:Proposed_Features/Multiple_addresses 
 none of the comments was in favor of this proposal.



On Mon, Oct 21, 2013 at 2:38 PM, Marc Gemis marc.ge...@gmail.com 
mailto:marc.ge...@gmail.com wrote:



2013/10/21 Pierre Parmentier pierrecparment...@gmail.com
mailto:pierrecparment...@gmail.com

  # Proposed Features/Multiple addresses

http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses



I don't like this proposal too much. This is a relation in
disguise. So why not use a real relation instead ? A building
relation (which already exists) with multiple address node
members.  -- I know it's not your proposal, so I won't shoot the
messenger :-)
This is a mess to maintain if you have to manually make sure that
all numbers behind a addr: are there. I would vote against it.

m.




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


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

Re: [OSM-talk-be] CRAB Import Tool

OK de relatie it is! :-)

Met vriendelijke groeten,
Best regards,

Ben Abelshausen



2013/10/20 Marc Gemis marc.ge...@gmail.com

 relatie is voor mij ok, en waarschijnlijk voor alle ervaren JOSM mappers
 ook wel. de anderen zullen we dan ervaren moeten maken :-)

 m


 2013/10/19 Kurt Roeckx k...@roeckx.be

 On Sat, Oct 19, 2013 at 02:00:12PM +0200, Ben Abelshausen wrote:
  Hallo,
 
  Wat zeg ik nu om de adressen te importeren?
 
  Het is het één of het ander:
 
  - Alles op de node.
  - Alles op relatie behalve nummer.

 Ik dacht dat het al duidelijk was, maar ik ben voorstaander van
 het op de relatie te doen.


 Kurt


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



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


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

Re: [OSM-talk-be] CRAB Import Tool

On Sun, Oct 20, 2013 at 5:35 PM, Kurt Roeckx k...@roeckx.be wrote:

 So one thing I noticed is that they contain dates from when the
 housenumber was valid until when it stopped being valid.  For the
 cases I've looked at, it seems that you just imported those
 housenumbers, even though they really don't seem to exist anymore.
 So can you take a look at how you generate those files?

 I'm also wandering if we want to add some kind of reference to
 the ID from CRAB.


Hi Kurt,

I will investigate the end-date issue. :-)

I'm not in favour of keeping external id's in OSM, the address itself
should be the id and you cannot rely on it staying on the map because
anyone can remove it.

Met vriendelijke groeten,
Best regards,

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

Re: [OSM-talk-be] CRAB Import Tool

2013-10-21 Thread Kurt Roeckx

On Mon, Oct 21, 2013 at 08:05:50PM +0200, Ben Abelshausen wrote:
  I'm also wondering if we want to add some kind of reference to
  the ID from CRAB.
 I'm not in favour of keeping external id's in OSM, the address itself
 should be the id and you cannot rely on it staying on the map because
 anyone can remove it.

I was just thinking about how to keep in sync with their database,
and to try and find out which points are mapped and which are not.

I'm also considering trying to do a full import and merging
existing nodes / houses with their data and things like that.  I
would actually like to mostly automate importing updates comming
from them.  I think that at some point we will at least need a way
to see see the difference between the 2, and having a direct
relation betweem them could make things easier.


Kurt


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

Re: [OSM-talk-be] biweekly hangout meetings

Are there any good examples of what they expect for each of those missing
sections ?

m


On Mon, Oct 21, 2013 at 8:01 PM, Ben Abelshausen
ben.abelshau...@gmail.comwrote:


 On Sun, Oct 20, 2013 at 11:43 AM, Marc Gemis marc.ge...@gmail.com wrote:

 1) Configure JOSM for remote control
 2) Use the demo site with the housenumbers in Lille to download data
 3) Work with layers in JOSM -- load OSM data in another layer
 4) layer switching and copy between layers.
 5) merge AGIV data with OSM data
 5.1 single house
 5.1.1 there is no single house
 5.1.2 there is a house
 5.1.3 there is a badly shaped house (perhaps even splitted in parts that
 have to be merged)
 5.2 two semi-detached houses
 5.2.1 there is no building
 5.2.2. there is a not splitted building
 5.2.3 there is a splitted building
 5.3 a terrace
 5.3.1 there is no building
 5.3.2 there is just a rectangle
 5.3.2 there is a complex building outline
 5.3.4  all individual houses are in OSM
 5.4 there is a multipolygon (although I don't know yet how I would solve
 this one)
 5.5. Keep the associatedStreet relation  addr:street tags correct
  will depend on what the import tool makes
 5.6 street name corrections and splitting street
 5.7 other things you can add (crossings, give_ways, ...)
 6) How to deal with the associatedStreet relation
 -- assuming the import generates such a relation
 6.1 how to add existing houses with numbers
 6.2 deleting duplicates caused by 6.1
 6.3 what if there is already an associatedStreet relation
 7) Dealing with POIs


 We also need to complete the procedure here:

 http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import

 and still discuss with the imports-list to avoid problems.

 Met vriendelijke groeten,
 Best regards,

 Ben Abelshausen


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


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

Re: [OSM-talk-be] CRAB Import Tool


On 2013-10-21 20:57, Kurt Roeckx wrote:

On Mon, Oct 21, 2013 at 08:05:50PM +0200, Ben Abelshausen wrote:

I'm also wondering if we want to add some kind of reference to
the ID from CRAB.

I'm not in favour of keeping external id's in OSM, the address itself
should be the id and you cannot rely on it staying on the map because
anyone can remove it.

I was just thinking about how to keep in sync with their database,
and to try and find out which points are mapped and which are not.

I'm also considering trying to do a full import and merging
existing nodes / houses with their data and things like that.  I
would actually like to mostly automate importing updates comming
from them.  I think that at some point we will at least need a way
to see see the difference between the 2, and having a direct
relation betweem them could make things easier.


Yup, you'll need a foreign key if you want to manage that 
automatically.  I aggree.  If not you could endup merging the same stuff 
all over again.  Or worse, delete old nodes and create new ones, 
enlarging the changesets.


But I would caution for doing an automagical full import and merge 
unless you're doing only for the referenced stuff, but new data and 
merged I would stll want to review it.   I've hardly ever had this sort 
of database migration work at the first attempt


Now lets hope someone at CRAB isn't planning on doing the same but in 
the other direction ;-) , I keep wondering what kind of feedback loop 
that would create


Glenn


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

Re: [OSM-talk-be] CRAB Import Tool

Met vriendelijke groeten,
Best regards,

Ben Abelshausen



On Mon, Oct 21, 2013 at 9:26 PM, Glenn Plas gl...@byte-consult.be wrote:

 On 2013-10-21 20:57, Kurt Roeckx wrote:

 On Mon, Oct 21, 2013 at 08:05:50PM +0200, Ben Abelshausen wrote:

 I'm also wondering if we want to add some kind of reference to
 the ID from CRAB.

 I'm not in favour of keeping external id's in OSM, the address itself
 should be the id and you cannot rely on it staying on the map because
 anyone can remove it.

 I was just thinking about how to keep in sync with their database,
 and to try and find out which points are mapped and which are not.

 I'm also considering trying to do a full import and merging
 existing nodes / houses with their data and things like that.  I
 would actually like to mostly automate importing updates comming
 from them.  I think that at some point we will at least need a way
 to see see the difference between the 2, and having a direct
 relation betweem them could make things easier.


 Yup, you'll need a foreign key if you want to manage that automatically.
  I aggree.  If not you could endup merging the same stuff all over again.
  Or worse, delete old nodes and create new ones, enlarging the changesets.

 But I would caution for doing an automagical full import and merge unless
 you're doing only for the referenced stuff, but new data and merged I would
 stll want to review it.   I've hardly ever had this sort of database
 migration work at the first attempt

 Now lets hope someone at CRAB isn't planning on doing the same but in the
 other direction ;-) , I keep wondering what kind of feedback loop that
 would create

 Glenn



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

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

Re: [OSM-talk-be] CRAB Import Tool

Oeps, sorry for the empty mail! :-)

I think we can use CRAB as a source but we will never be able to update
automatically but even without an ID we should be able to detect changes
and if not then most likely there will be some error in OSM or CRAB (if
streetnames do not match or something).

I even think there is no 'one-id-per-address' in the CRAB datamodel. I will
ask someone on Wednesday when I will be back at AGIV but I think there are
only linked buildings/percelen and those tend to change too.

Met vriendelijke groeten,
Best regards,

Ben Abelshausen

On Mon, Oct 21, 2013 at 9:34 PM, Ben Abelshausen
ben.abelshau...@gmail.comwrote:

Met vriendelijke groeten,
Best regards,

Ben Abelshausen

On Mon, Oct 21, 2013 at 9:26 PM, Glenn Plas gl...@byte-consult.be wrote:

On 2013-10-21 20:57, Kurt Roeckx wrote:

On Mon, Oct 21, 2013 at 08:05:50PM +0200, Ben Abelshausen wrote:

I'm also wondering if we want to add some kind of reference to
the ID from CRAB.

I'm not in favour of keeping external id's in OSM, the address itself
should be the id and you cannot rely on it staying on the map because
anyone can remove it.

I was just thinking about how to keep in sync with their database,
and to try and find out which points are mapped and which are not.

I'm also considering trying to do a full import and merging
existing nodes / houses with their data and things like that. I
would actually like to mostly automate importing updates comming
from them. I think that at some point we will at least need a way
to see see the difference between the 2, and having a direct
relation betweem them could make things easier.

Yup, you'll need a foreign key if you want to manage that automatically.
I aggree. If not you could endup merging the same stuff all over again.
Or worse, delete old nodes and create new ones, enlarging the changesets.

But I would caution for doing an automagical full import and merge unless
you're doing only for the referenced stuff, but new data and merged I would
stll want to review it. I've hardly ever had this sort of database
migration work at the first attempt

Now lets hope someone at CRAB isn't planning on doing the same but in the
other direction ;-) , I keep wondering what kind of feedback loop that
would create

Glenn

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

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

Re: [OSM-talk-be] biweekly hangout meetings

On Mon, Oct 21, 2013 at 9:18 PM, Marc Gemis marc.ge...@gmail.com wrote:

 Are there any good examples of what they expect for each of those missing
 sections ?


There is a whole list here, one better than the other:

http://wiki.openstreetmap.org/wiki/Import/Catalogue

I like this one (not their complete approach but they have nice details).
Maybe we should meet again or hold a Google talk session on these topic
with those interested?

http://wiki.openstreetmap.org/wiki/Import/Catalogue/NYC_Buildings_Addresses

Met vriendelijke groeten,
Best regards,

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

Re: [OSM-talk-be] CRAB Import Tool

2013-10-21 Thread Kurt Roeckx

On Mon, Oct 21, 2013 at 09:40:07PM +0200, Ben Abelshausen wrote:
 I think we can use CRAB as a source but we will never be able to update
 automatically but even without an ID we should be able to detect changes
 and if not then most likely there will be some error in OSM or CRAB (if
 streetnames do not match or something).
 
 I even think there is no 'one-id-per-address' in the CRAB datamodel. I will
 ask someone on Wednesday when I will be back at AGIV but I think there are
 only linked buildings/percelen and those tend to change too.

They actually have pretty good documentation, and really thought
about their data model.  They have a total of 20 tables with
foreign keys between them.

Their is a many-to-many relationship between addresses and points
on the map.  That is a building can have multiple addresses, and
1 address can have multiple buildings.  An address can also have
subaddresses.  And each table has an ID in it.

Having the IDs in osm would make it a lot easier to compare the
databases.  Having 2 databases you can compare is very handy to
check for mistakes.

You can of course compare their old database against a newer and
try to import that, but I have a feeling that that is going to
give you more manual work in the long end.  I think it's important
to try automate things.

I really see no good reason not to add those IDs at this point.
I don't see the harm in them.  I can only see them being useful.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

2013-10-21 Thread Kurt Roeckx

On Mon, Oct 21, 2013 at 10:06:03PM +0200, Kurt Roeckx wrote:
 I really see no good reason not to add those IDs at this point.
 I don't see the harm in them.  I can only see them being useful.

I would actually want to propose a different import strategy:
- Add the CRAB IDs to all existing addresses in Flanders
- Import the rest or large parts of CRAB in one big import

The first part would actually be the hard part, and would need
to be done carefully.  It will probably require large parts to
be checked manually.  We would probably first need to fix our
existing data, which I think is useful to do anyway.

Therefor it would be useful that if you're going to import data
from CRAB that you don't complicate that and already import the
IDs.  It should then be possible to combine both ways of importing.

PS: Do we actually already have clearance to import this data?


Kurt


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

Re: [OSM-talk-be] biweekly hangout meetings

Gilbert,

jij hebt voordien al aangegeven te willen meewerken toen er nog sprake was
van een samenwerking met de Nederlanders. Is dit iets waar je ook wil bij
helpen ?

met vriendelijke groeten

m


On Mon, Oct 21, 2013 at 9:46 PM, Ben Abelshausen
ben.abelshau...@gmail.comwrote:


 On Mon, Oct 21, 2013 at 9:18 PM, Marc Gemis marc.ge...@gmail.com wrote:

 Are there any good examples of what they expect for each of those missing
 sections ?


 There is a whole list here, one better than the other:

 http://wiki.openstreetmap.org/wiki/Import/Catalogue

 I like this one (not their complete approach but they have nice details).
 Maybe we should meet again or hold a Google talk session on these topic
 with those interested?

 http://wiki.openstreetmap.org/wiki/Import/Catalogue/NYC_Buildings_Addresses

 Met vriendelijke groeten,
 Best regards,

 Ben Abelshausen

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


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

Re: [OSM-talk-be] CRAB Import Tool

So you are going to write an algorithm that matching addresses in OSM with
addresses in Crab in order to add an id. Right now there are already
addresses in OSM that are not in Crab. The same might happen next year.
People might have added POIs with addresses. So you will always need an
address based matching algorithm. So there is no reason to add the Crab id
in OSM.

What do you mean by Fix our data ? Is Crab suddenly the holy grail ?
Their DB contains mistakes as well. I'm against a full automatic import.
I'm still in favor of the workflow that Ben proposes. Using a website to
download a street. Manually merging with existing data, drawing buildings,
merging or splitting buildings were needed. Who wrote a few days back that
house nodes without buildings are not so good (I'm not saying it was you) ?
An automatic import cannot prevent that.

It would be nice though to have something like Jo did for the busstops.
Have a table for mismatches between the OSM data and the imported data.
Such a list could be generated every year to see which data should be added
or updated

regards

m


On Mon, Oct 21, 2013 at 10:45 PM, Kurt Roeckx k...@roeckx.be wrote:

 On Mon, Oct 21, 2013 at 10:06:03PM +0200, Kurt Roeckx wrote:
  I really see no good reason not to add those IDs at this point.
  I don't see the harm in them.  I can only see them being useful.

 I would actually want to propose a different import strategy:
 - Add the CRAB IDs to all existing addresses in Flanders
 - Import the rest or large parts of CRAB in one big import

 The first part would actually be the hard part, and would need
 to be done carefully.  It will probably require large parts to
 be checked manually.  We would probably first need to fix our
 existing data, which I think is useful to do anyway.

 Therefor it would be useful that if you're going to import data
 from CRAB that you don't complicate that and already import the
 IDs.  It should then be possible to combine both ways of importing.

 PS: Do we actually already have clearance to import this data?


 Kurt


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

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

[OSM-talk-be] Why I'm against a full automatic import (ook in het Nederlands) (Was CRAB Import Tool)

Nederlands onderaan

Allow me to explain why I'm against a full automatic import of the Crab
data, as proposed on this mailing list

I understand that this is the fastest way to get the data into OSM and
ready for use by everybody.
However, the data will then be owned by 1 or 2 people that did the import.
They will not be able to cope with the consequences of the data they
imported. The import software will have some flaws (double addresses,
missing buildings, bad buildings, problems with associatedStreet merging,
etc.)
Will you clean up the mess that others made ?

If, on the other hand, you allow people to import their own chunks of data
(via the tool made by the French, a lot of people own the data. Every
contributor takes some pride in the data s/he added and will be glad to
make corrections to it. Even during the initial import improvements to the
imported  existing data will be made. The more people that do this, the
better.

It's all about community building. Build a community around this import.
This community will do other things as well afterwards.

You can hear the same message in all presentations on import at the SOTM US
and SOTM conferences. Please take a look at those videos.


- Nederlands---
Sta me toe om uit te leggen waarom ik tegen een volledige geautomatiseerde
import van Crab data ben, zoals ergens voorgesteld werd.

Ik begrijp dat sommigen de data snel in OSM willen krijgen, zodat het door
iedereen kan gebruikt worden. Het gevolg daarvan is dat de gegevens door 1
of 2 mensen aangemaakt is. Zij kunnen niet alle probleempjes oplossen die
ontstaan door deze invoer. Ik denk hierbij aan foutjes in de software die
ervoor zorgen dat er dubbele adressen zijn of problemen met de
associatedStreet-relaties. Ook wordt er tijdens de import ook niks gedaan
aan ontbrekende of foutieve gebouwen. Wie gaat die problemen aanpakken die
door anderen gemaakt zijn ?

Als je aan de andere kant, iedereen toelaat om stukjes gegevens te
importeren en onmiddellijk te verbeteren, krijg je een groep van mensen die
de gegevens bezit/beheert. Deze mensen gaan in zekere zin fier zijn op hun
werk en proberen de fouten eruit te halen. Hoe meer van deze mensen hoe
beter.

Het gaat dus over het opbouwen van een community. Bouw aub een community op
rond deze import. Op langere termijn zal osm er wel bij varen.

I meen deze boodschap ook te horen in alle presentaties rond imports die
gegeven zijn op de SOTM US en SOTM conferenties. Kijk maar eens naar die
videos. (wel in het Engels)

groeten

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

Re: [OSM-legal-talk] License / Copyright - OSM data for commercial use artistic map

2013-10-21 Thread Jonathan Harley


On 19/10/13 11:11, Beri Dániel wrote:


Dear All,

I would like you to have a look at my question I posted in the OSM 
forum yesterday. It is not an urgent matter, I'm duplicating it here 
as well because I would like to avoid any mistreatment of the OSM 
licenses.


Below you can read my post from the forum, or just simply have a look 
at it in the forum itself: 
http://forum.openstreetmap.org/viewtopic.php?id=22948



Thanks in advance!

Daniel



Hi Dániel, overall your project does sound like what's presented to 
users would be a produced work and there is no problem with commercial 
use. AFAIK OpenLayers uses the FreeBSD license which places no 
limitations on use other than that you must distribute it with its 
license intact.


The only part which would constitute a derivative database is your 
altered OSM data (point 2). This altered data will clearly be derived 
from OSM's data and you would need to publish this under ODbL. If you 
store the data about where your users live (point 5) in a database, and 
if this data is derived from the OSM map (users drop a pin on your map 
based on what they see on it, or where the OSM-based search server said 
they are), then this is also a derivative database and must also be made 
available under ODbL.


Note that a database here just means a data set - the set of data that 
was derived from OSM. The ODbL license does not extend virally to any 
other data sets you may happen to store in the same database management 
system. The derived data is the only thing you must distribute freely 
(if asked to), and you can retain all rights on your other data, images 
and published maps.


HTH - Jonathan





Dear All,

This might have been discussed several times, hence sorry for raising 
this question again, but I really would like to make sure that I'm in 
compliance with the rules of the OSM license. (Also, I'm not a 
programmer, so, sorry for formulating the details of my envisaged 
project with lack/inproper use of the programming jargon.)


So, here is the list of things I am planning to do:

I would like to create an artistic map
1) *based on OSM data* - I would need a world map, with territories of 
countries and potentially subdivisions as well
2) *I would alter the OSM data* by defining new, custom subdivisions 
in certain areas, like cutting half a country (or continent, like 
Antarctica) not along any currently available line, but according to 
my wish
3) I would like to *put copyrighted images* onto these subdivisions 
(with OpenLayers)
4) I would *remove uneccessary detail by not rendering some types of 
features*, ie. I don't want any other data to be displayed on the map, 
but the original and custom-made subdivision borders and the images
5) however, *in the background I would like to still use the OSM 
data*, so that users could search, eg. the address of their home, then 
the map would display the place where they live, but covered with the 
image I defined to cover that particular place with (ie. not 
displaying any roads etc.)
6) I would expect volume of use too high to be supportable by OSM's 
tile servers, therefore I *would have my own tile server*
7) Also, because of point 6, I *would create separate, own search 
server* as well, not to overwhelm Nominatim's servers (btw, I would 
really appreciate if you could help me with auto-complete search, is 
there any advanced solution already?)


So the end-result would look like this world map of flags, with the 
exception that I would make it available online as a dynamic map and 
in print as well:


500px-Flag-map_of_the_world.svg.png

So, my questions are:
1) does this project qualify to be a *produced work* as defined in use 
case 2 of the license? http://wiki.openstreetmap.org/wiki/Lice … 
thing_else 
http://wiki.openstreetmap.org/wiki/License/Use_Cases#Case_2:_I_want_to_publish_something_based_on_OSM_and_nothing_else

2) if not, then *which use case is the applicable here*?
3) in either case, what are the *consequences of the license to my 
rights over parts of the project* (database, separate copyrighted 
images and the overall look of the map)? what should be shared freely? 
Can I reserve the right to the overall image of the map to be sold eg. 
as a printed poster?
4) Also, does *OpenLayers' license* (in which I would define the new 
layer of images) interfere with this idea to be used for commercial 
use and reserve the rights for the end product?


Sorry if the questions should be super-obvious based on the 
wikis/forum etc., they aren't really self-explanatory for me! smile


Thank you very much in advance!
Best regards,
underclover



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



--
Dr Jonathan Harley   :Managing Director:   SpiffyMap Ltd

m...@spiffymap.com  Phone: 0845 313 8457 www.spiffymap.com
The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ,

Re: [OSM-legal-talk] License / Copyright - OSM data for commercial use artistic map

2013-10-21 Thread Beri Dániel

Hi Jonathan!

Thank you very much for clearing things up, and explaining the difference
between the treatment of data sets and other things I would put on the map.

The treatment of OSM *data*, and the alteration of it is fine, understood,
and obviuosly I can live with it.

Although, the licensing/copyright of the *layer* which I would ask my
programmer to define in OpenLayers and which then would be filled with
images is still a bit fuzzy. Aren't these two statements opposite to each
other:

   1. OpenLayers uses the FreeBSD license which places no limitations on
   use other than that you must distribute it with its license intact.
   2. you can retain all rights on your other data, images and *published
   maps*

What would Point1 include in itself? Maybe I misunderstood the whole
concept of the word layer. I thought that the visual outlook of the map
what makes it a map, what people see (and in may case consists of the
collection of images put together) is on a layer and hence should be
distributed accordingly?

This would imply that I could I ask the author of this
projechttp://nordpil.com/go/products/stockholm-papercraft/t
to distribute the layer he defined? (Obviously I don't want to, as I cheer
for Point2 to be true in case of my project as well :)

Thanks in advance again!

Daniel




On 21 October 2013 11:25, Jonathan Harley j...@spiffymap.net wrote:

 On 19/10/13 11:11, Beri Dániel wrote:


 Dear All,

 I would like you to have a look at my question I posted in the OSM forum
 yesterday. It is not an urgent matter, I'm duplicating it here as well
 because I would like to avoid any mistreatment of the OSM licenses.

 Below you can read my post from the forum, or just simply have a look at
 it in the forum itself: http://forum.openstreetmap.**
 org/viewtopic.php?id=22948http://forum.openstreetmap.org/viewtopic.php?id=22948


 Thanks in advance!

 Daniel


 Hi Dániel, overall your project does sound like what's presented to users
 would be a produced work and there is no problem with commercial use. AFAIK
 OpenLayers uses the FreeBSD license which places no limitations on use
 other than that you must distribute it with its license intact.

 The only part which would constitute a derivative database is your altered
 OSM data (point 2). This altered data will clearly be derived from OSM's
 data and you would need to publish this under ODbL. If you store the data
 about where your users live (point 5) in a database, and if this data is
 derived from the OSM map (users drop a pin on your map based on what they
 see on it, or where the OSM-based search server said they are), then this
 is also a derivative database and must also be made available under ODbL.

 Note that a database here just means a data set - the set of data that
 was derived from OSM. The ODbL license does not extend virally to any other
 data sets you may happen to store in the same database management system.
 The derived data is the only thing you must distribute freely (if asked
 to), and you can retain all rights on your other data, images and published
 maps.

 HTH - Jonathan


  

 Dear All,

 This might have been discussed several times, hence sorry for raising
 this question again, but I really would like to make sure that I'm in
 compliance with the rules of the OSM license. (Also, I'm not a programmer,
 so, sorry for formulating the details of my envisaged project with
 lack/inproper use of the programming jargon.)

 So, here is the list of things I am planning to do:

 I would like to create an artistic map
 1) *based on OSM data* - I would need a world map, with territories of
 countries and potentially subdivisions as well
 2) *I would alter the OSM data* by defining new, custom subdivisions in
 certain areas, like cutting half a country (or continent, like Antarctica)
 not along any currently available line, but according to my wish
 3) I would like to *put copyrighted images* onto these subdivisions (with
 OpenLayers)
 4) I would *remove uneccessary detail by not rendering some types of
 features*, ie. I don't want any other data to be displayed on the map, but
 the original and custom-made subdivision borders and the images
 5) however, *in the background I would like to still use the OSM data*,
 so that users could search, eg. the address of their home, then the map
 would display the place where they live, but covered with the image I
 defined to cover that particular place with (ie. not displaying any roads
 etc.)
 6) I would expect volume of use too high to be supportable by OSM's tile
 servers, therefore I *would have my own tile server*
 7) Also, because of point 6, I *would create separate, own search server*
 as well, not to overwhelm Nominatim's servers (btw, I would really
 appreciate if you could help me with auto-complete search, is there any
 advanced solution already?)


 So the end-result would look like this world map of flags, with the
 exception that I would make it available online as a dynamic

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Nick Whitelegg


I'd go the other way and abolish Winter Time. ;-)
No DST = dark summer evenings. Not nice!

Going on topic, not sure if something like time zones belongs in OSM. Would it 
not be better to use a more specialised web service to look up time zones for a 
given lat/lon? I'd prefer to minimise overloading OSM with things which are not 
on the ground data. For one thing, it means bigger planet files and more 
demands on software to extract the data you want.

Nick

-moltonel 3x Combo molto...@gmail.com wrote: -

Actually, I always wondered why timezones were kept out of OSM. I know DST 
complicates tagging (it'll be the first thing I abolish when I become World 
Dictator), ...

  
___
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] Timezones (was: Deleting data)

2013-10-21 Thread Colin Smale

 

Nick, this can be done for admin boundaries as well. Would you advocate
removing them from OSM as well? The change to the size of the planet
file if timezones are included is absolutely microscopic in the big
scheme of things. There are clearly many shades of grey. It's a question
of where to draw the line (as it were). Can this be expressed
objectively? 

It feels rather weird that some people are now advocating keeping
certain things out of OSM. The traditional consensus is that anyone can
put anything in OSM and that any attempt to limit people's creativity is
met with much scepticism. In the continuum between the puritans and the
pragmatists there's plenty of room for everyone. 

I for one think that data in OSM should be above all usable. Whether to
have timezones in OSM is analogous to database normalisation. If taken
to extremes, you can win a theoretical point while at the same time
causing significant performance problems and extra complexity for the
users of the data. 

Colin 

On 2013-10-21 10:55, Nick Whitelegg wrote: 

 I'd go the other way and abolish Winter Time. ;-)
 No DST = dark summer evenings. Not nice!
 
 Going on topic, not sure if something like time zones belongs in OSM. Would 
 it not be better to use a more specialised web service to look up time zones 
 for a given lat/lon? I'd prefer to minimise overloading OSM with things which 
 are not on the ground data. For one thing, it means bigger planet files and 
 more demands on software to extract the data you want.
 
 Nick
 
 -moltonel 3x Combo molto...@gmail.com wrote: - 
 
 Actually, I always wondered why timezones were kept out of OSM. I know DST 
 complicates tagging (it'll be the first thing I abolish when I become World 
 Dictator), ... 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk [1]
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk [1]
 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Pieren

On Mon, Oct 21, 2013 at 11:19 AM, Colin Smale colin.sm...@xs4all.nl wrote:
 The traditional consensus is that anyone can put anything
 in OSM

It was only a consensus in the group of contributors thinking that
(which is then easy to reach a consensus).
This remembers me similars discussions about:
- hi-res aerial imagery coverage by huge polygons (Yahoo!)
- parcels
- underground facilities (sewer, parkings, phone cables)
- geologic stuff (mountain strings, stratifications)

All such features have the problem that they are often not verifiable
(underground) or creates high density maps with many different layers
where none of the OSM editors can handle easily and correctly
different layers making the map unreadable and unworkable
(parcels, sewer, air lines) or that polygons are so big that nobody is
able to maintain them correctly (coastlines) or too fuzzy to represent
something real with a sharp line (e.g. mountains strings, valleys). So
no, you cannot say that OSM can be a garbage collector for all data as
soon as you can draw them on a map.

Pieren

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Colin Smale

 

Another popular view is that these are problems for the renderer/editor,
not intrinsic issues with the data. sarcasmTag as you see fit and the
renderers/editors will catch up!/sarcasm The fact that coastlines are
difficult to maintain with the current toolset is not an argument to not
have them in OSM. 

Back on topic: how do you phrase an objective rule, or at least
well-worded guidelines, which allow admin boundaries but disallow time
zone boundaries? I wonder where the UK ceremonial counties, fire
department areas, national parks etc will end up. My point is, gut
feelings aside, that it is not reasonable to single out TZ boundaries
for this deprecation. 

Colin 

On 2013-10-21 13:14, Pieren wrote: 

 On Mon, Oct 21, 2013 at 11:19 AM, Colin Smale colin.sm...@xs4all.nl wrote:
 
 The traditional consensus is that anyone can put anything in OSM
 
 It was only a consensus in the group of contributors thinking that
 (which is then easy to reach a consensus).
 This remembers me similars discussions about:
 - hi-res aerial imagery coverage by huge polygons (Yahoo!)
 - parcels
 - underground facilities (sewer, parkings, phone cables)
 - geologic stuff (mountain strings, stratifications)
 
 All such features have the problem that they are often not verifiable
 (underground) or creates high density maps with many different layers
 where none of the OSM editors can handle easily and correctly
 different layers making the map unreadable and unworkable
 (parcels, sewer, air lines) or that polygons are so big that nobody is
 able to maintain them correctly (coastlines) or too fuzzy to represent
 something real with a sharp line (e.g. mountains strings, valleys). So
 no, you cannot say that OSM can be a garbage collector for all data as
 soon as you can draw them on a map.
 
 Pieren
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk [1]
 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Lester Caine


Colin Smale wrote:

My point is, gut feelings aside, that it is not reasonable to single out TZ
boundaries for this deprecation.


Actually having accurate TZ boundaries in OSM is probably more important than 
some of the political boundaries. The reason I've been looking into this is 
simply because other sources of TZ data are badly broken near boundaries ...


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

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013/10/21 Pieren pier...@gmail.com

 It was only a consensus in the group of contributors thinking that
 (which is then easy to reach a consensus).
 This remembers me similars discussions about:
 - hi-res aerial imagery coverage by huge polygons (Yahoo!)



agree that this is not really a datum suitable (from a puristic view point)
for osm, but on the other hand there are mappers in certain areas with
worse coverage than your average European Country, where they misuse the
osm db for this kind of information (and it makes it easy for them to
maintain this data together) and then improve the map with stuff we all
want to have (based on these boundaries their workflow is much easier).
Yes, you could say that there could be a different workflow suitable
without putting these polygons into our db, but maybe they don't have to
capacities, and surely the overhead of these few and simple polygons is
very low, so I tend to suggest to let them do it.



 - parcels



IMHO there is really no good reason not to put parcel data, as many of our
other data actually depends on them (landuse and addresses), besides that
we're probably not prepared currently because of the sheer quantity.


- underground facilities (sewer, parkings, phone cables)



are a little bit difficult (verificability unless there are public
datasets) probably also maintenance (as this is something that very few
people map and hence verify / correct).



 - geologic stuff (mountain strings, stratifications)



geologic stuff (stratifications) doesn't belong to OSM IMHO (data not
surveyable/verificable by the crowd,  resolution not adequate to the rest
of our data).
By mountain string, are you refering to mountain ranges? IMHO ridges and
arêtes are suitable (simple lines, well defined, surveyable), making a
collection of these ridges to get a mountain range might be doable.


 All such features have the problem that they are often not verifiable
 (underground) or creates high density maps with many different layers
 where none of the OSM editors can handle easily and correctly
 different layers



Some of these are NOT different layers (except the geologic stratifications
and the aerial imagery coverage). As they depend one of eachother (e.g.
landuses depend on parcels, addresses depend (at least in some countries)
on parcels, even underground lines depend often on what is above ground and
vice versa) they should not be disjunct.


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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Jukka Rahkonen

 I'd go the other way and abolish Winter Time. ;-)
 No DST = dark summer evenings. Not nice!

 Going on topic, not sure if something like time zones
 belongs in OSM. Would it not be better to use a more 
 specialised web service to look up time zones for a 
 given lat/lon? I'd prefer to minimise overloading 
 OSM with things which are not on the ground data. 
 For one thing, it means bigger planet files and more 
 demands on software to extract the data you want.

A handful of polygons is no trouble to handle in the GIS world but our
self-made problem is that we must convert nice simple polygons into heavy
relations. Perhaps area primitives will come true one day and give some help
https://wiki.openstreetmap.org/wiki/The_Future_of_Areas.

-Jukka Rahkonen-

 Nick


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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Toby Murray

On Mon, Oct 21, 2013 at 6:29 AM, Colin Smale colin.sm...@xs4all.nl wrote:

 Back on topic: how do you phrase an objective rule, or at least
 well-worded guidelines, which allow admin boundaries but disallow time zone
 boundaries? I wonder where the UK ceremonial counties, fire department
 areas, national parks etc will end up. My point is, gut feelings aside,
 that it is not reasonable to single out TZ boundaries for this deprecation.


 Having edited over a thousand of them, I would not be sad to see admin
boundaries removed from the general OSM database. I think Russ is on to
something with his ClosedStreetMap concept although that is some terrible
branding so we need another name :) But at the end of the day, we are
terrible at maintaining such boundaries and very good at breaking them in
OSM, mostly because they are usually hard/impossible to spot on the ground
and verify. So people see random lines going through the area they are
trying to map and either don't pay attention when they touch them or just
delete them outright. Essentially what we need is the concept of layers. If
all the admin/timezone boundaries were in their own layer and didn't
interact with roads, rivers, etc in OSM then they would be much easier to
keep up to date from external sources.

Yes, OSM *can* contain just about anything. But if we are terrible at it
and there are other datasets available that aren't terrible then why should
we try to poorly duplicate others efforts?

Some of my opinion may be due to some problems with the way they were
imported here in the US but I suspect it isn't all that different in most
other places.

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Philip Barnes

It is not always possible to separate admin boundaries from real world 
features. Rivers, roads or even hedges often define a boundary.

Phil (trigpoint)
--

Sent from my Nokia N9



On 21/10/2013 15:41 Toby Murray wrote:

On Mon, Oct 21, 2013 at 6:29 AM, Colin Smale colin.sm...@xs4all.nl wrote:
Back on topic: how do you phrase an objective rule, or at least well-worded 
guidelines, which allow admin boundaries but disallow time zone boundaries? I 
wonder where the UK ceremonial counties, fire department areas, national parks 
etc will end up. My point is, gut feelings aside, that it is not reasonable to 
single out TZ boundaries for this deprecation.


Having edited over a thousand of them, I would not be sad to see admin 
boundaries removed from the general OSM database. I think Russ is on to 
something with his ClosedStreetMap concept although that is some terrible 
branding so we need another name :) But at the end of the day, we are terrible 
at maintaining such boundaries and very good at breaking them in OSM, mostly 
because they are usually hard/impossible to spot on the ground and verify. So 
people see random lines going through the area they are trying to map and 
either don't pay attention when they touch them or just delete them outright. 
Essentially what we need is the concept of layers. If all the admin/timezone 
boundaries were in their own layer and didn't interact with roads, rivers, 
etc in OSM then they would be much easier to keep up to date from external 
sources.


Yes, OSM *can* contain just about anything. But if we are terrible at it and 
there are other datasets available that aren't terrible then why should we try 
to poorly duplicate others efforts?


Some of my opinion may be due to some problems with the way they were imported 
here in the US but I suspect it isn't all that different in most other places.


Toby

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Clifford Snow

On Mon, Oct 21, 2013 at 7:41 AM, Toby Murray toby.mur...@gmail.com wrote:

 Having edited over a thousand of them, I would not be sad to see admin
 boundaries removed from the general OSM database. I think Russ is on to
 something with his ClosedStreetMap concept although that is some terrible
 branding so we need another name :) But at the end of the day, we are
 terrible at maintaining such boundaries and very good at breaking them in
 OSM, mostly because they are usually hard/impossible to spot on the ground
 and verify. So people see random lines going through the area they are
 trying to map and either don't pay attention when they touch them or just
 delete them outright. Essentially what we need is the concept of layers. If
 all the admin/timezone boundaries were in their own layer and didn't
 interact with roads, rivers, etc in OSM then they would be much easier to
 keep up to date from external sources.


Introducing layers, although difficult to implement, would certainly
simplify editing. Moving admin boundaries and land use polygons to a
layer(s) would simplify basic editing. No more connecting roads to
boundaries and land use edges. Layers could even introduce the concept of
limiting permissions to edit.


-- 
Clifford

OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Upcoming website features

2013-10-21 Thread John Firebaugh

Thanks everyone for the feedback on the redesign effort.

Development work on the redesign is in a lull right now due to competing
priorities, but we hope to get back to it and continue refining the design
in the near future, and we'll be taking your comments here and on the pull
request into account.

Also, thanks to Paul for the status updates -- I think they're an effective
way to keep interested people in the loop.

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Toby Murray

Yes, in that small fraction of cases there would be duplication of
positional data. But in some cases where you think this is the case, it
might actually not be. My county border was defined by a river. Now part of
the river is a reservoir and the other part has shifted over time and
through floods. The border was not moved with these changes and still
follows the original course of the river even though there is no way to see
this path on the ground at this point. So is the border really defined by
the river? Or was it defined by the river at a certain point in time which
may or may not be the same as it is now.

Don't get me wrong, I'm not suggesting an edit to nuke all admin boundaries
tomorrow. They are a part of the core OSM database and will likely continue
to be for some time. I'm just pointing out that OSM is not good at them and
that there might be a better way to handle such things. Perhaps this
approach could be tried with time zone data since we don't already have a
large body of them in the database.

Toby


On Mon, Oct 21, 2013 at 9:54 AM, Philip Barnes p...@trigpoint.me.uk wrote:

 It is not always possible to separate admin boundaries from real world
 features. Rivers, roads or even hedges often define a boundary.


 Phil (trigpoint)

 --



 Sent from my Nokia N9



 On 21/10/2013 15:41 Toby Murray wrote:
 On Mon, Oct 21, 2013 at 6:29 AM, Colin Smale colin.sm...@xs4all.nlwrote:

  Back on topic: how do you phrase an objective rule, or at least
 well-worded guidelines, which allow admin boundaries but disallow time zone
 boundaries? I wonder where the UK ceremonial counties, fire department
 areas, national parks etc will end up. My point is, gut feelings aside,
 that it is not reasonable to single out TZ boundaries for this deprecation.


 Having edited over a thousand of them, I would not be sad to see admin
 boundaries removed from the general OSM database. I think Russ is on to
 something with his ClosedStreetMap concept although that is some terrible
 branding so we need another name :) But at the end of the day, we are
 terrible at maintaining such boundaries and very good at breaking them in
 OSM, mostly because they are usually hard/impossible to spot on the ground
 and verify. So people see random lines going through the area they are
 trying to map and either don't pay attention when they touch them or just
 delete them outright. Essentially what we need is the concept of layers. If
 all the admin/timezone boundaries were in their own layer and didn't
 interact with roads, rivers, etc in OSM then they would be much easier to
 keep up to date from external sources.

 Yes, OSM *can* contain just about anything. But if we are terrible at it
 and there are other datasets available that aren't terrible then why should
 we try to poorly duplicate others efforts?

 Some of my opinion may be due to some problems with the way they were
 imported here in the US but I suspect it isn't all that different in most
 other places.

 Toby


 ___
 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] Timezones

2013-10-21 Thread Tom Taylor

Supposing I wanted to undertake a project to solve this class of 
problem, either using layers or areas or something e3lse. I imagine the 
project would have a number of peices, since it affects the database, 
editors, rendering tools, and heaven knows what else.


On which list would we flesh out requirements? Then on which list would 
we architect a solution? And finally, on which list would we coordinate 
solution development?


Tom Taylor
TomT5454

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Markus Lindholm

On 21 October 2013 16:41, Toby Murray toby.mur...@gmail.com wrote:
 Having edited over a thousand of them, I would not be sad to see admin
 boundaries removed from the general OSM database. I think Russ is on to
 something with his ClosedStreetMap concept although that is some terrible
 branding so we need another name :) But at the end of the day, we are
 terrible at maintaining such boundaries and very good at breaking them in
 OSM, mostly because they are usually hard/impossible to spot on the ground
 and verify. So people see random lines going through the area they are
 trying to map and either don't pay attention when they touch them or just
 delete them outright. Essentially what we need is the concept of layers. If
 all the admin/timezone boundaries were in their own layer and didn't
 interact with roads, rivers, etc in OSM then they would be much easier to
 keep up to date from external sources.

 Yes, OSM *can* contain just about anything. But if we are terrible at it and
 there are other datasets available that aren't terrible then why should we
 try to poorly duplicate others efforts?

I think you're overlooking a key strength with the osm database, that
all the map features are integrated, e.g. if a kiosk is mapped to be
three meters to the left of the entrance to the building, and that is
also the ground truth, then you have that fact of their interrelation.
With different datasets from different sources, you lose it.

/Markus

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Johan C

 Essentially what we need is the concept of layers.

Layers do have disadvantages, how to prevent data being mapped in the wrong
layer for instance. I however do see the point that mappers, especially
newbies, break administrative boundaries. If that happens a lot, it might
be easier to 'grey them out' in any editor by default, making sure that a
mapper has to use a check box or so to change these boundaries.


2013/10/21 Markus Lindholm markus.lindh...@gmail.com

 On 21 October 2013 16:41, Toby Murray toby.mur...@gmail.com wrote:
  Having edited over a thousand of them, I would not be sad to see admin
  boundaries removed from the general OSM database. I think Russ is on to
  something with his ClosedStreetMap concept although that is some
 terrible
  branding so we need another name :) But at the end of the day, we are
  terrible at maintaining such boundaries and very good at breaking them in
  OSM, mostly because they are usually hard/impossible to spot on the
 ground
  and verify. So people see random lines going through the area they are
  trying to map and either don't pay attention when they touch them or just
  delete them outright. Essentially what we need is the concept of layers.
 If
  all the admin/timezone boundaries were in their own layer and didn't
  interact with roads, rivers, etc in OSM then they would be much easier to
  keep up to date from external sources.
 
  Yes, OSM *can* contain just about anything. But if we are terrible at it
 and
  there are other datasets available that aren't terrible then why should
 we
  try to poorly duplicate others efforts?

 I think you're overlooking a key strength with the osm database, that
 all the map features are integrated, e.g. if a kiosk is mapped to be
 three meters to the left of the entrance to the building, and that is
 also the ground truth, then you have that fact of their interrelation.
 With different datasets from different sources, you lose it.

 /Markus

 ___
 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] Timezones (was: Deleting data)



 Am 21/ott/2013 um 17:09 schrieb Clifford Snow cliff...@snowandsnow.us:
 
 Introducing layers, although difficult to implement, would certainly simplify 
 editing. Moving admin boundaries and land use polygons to a layer(s) would 
 simplify basic editing. No more connecting roads to boundaries and land use 
 edges.


while landuse really won't end in the middle of a road in low scales, 
boundaries might be defined by rivers or roads, so disconnecting them would be 
wrong.

Still you can simulate layers with the filter function, but you should be 
careful when using them.

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

Re: [OSM-talk] Timezones (was: Deleting data)

2013-10-21 Thread Bryce Nesbitt

On Mon, Oct 21, 2013 at 2:11 PM, Johan C osm...@gmail.com wrote:

  Essentially what we need is the concept of layers.


I don't think we really need layers, but could use editors that are
semantically aware of things like boundaries,
and put them in the background until needed.

---

Some boundaries effectively follow an other mapped feature,even if the true
boundary varies.  A nature reserve on one side of a
road, or one side of a winding river, may fall into this category.  The
conventional boundary is shared.  The actual legal
boundary must be established by survey and is less relevant to OSM.   If we
can make sharing boundaries less awkward to edit,
I think we'd unlock a lot of power in modelling the world as it really is
used.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Timezones (was: Deleting data)

On Tue, Oct 22, 2013 at 7:07 AM, Bryce Nesbitt bry...@obviously.com wrote:

 On Mon, Oct 21, 2013 at 2:11 PM, Johan C osm...@gmail.com wrote:

  Essentially what we need is the concept of layers.


 I don't think we really need layers, but could use editors that are
 semantically aware of things like boundaries,
 and put them in the background until needed.



JOSM can do this (this was probably mentioned before).
so just 2 more editors to go :-)

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

Re: [talk-au] Openstreetmap Quality Issues

2013-10-21 Thread Nick Hocking

Hi Neil,
I think the way to get this fixed permanently could be...

Fix it one more time, re-add the note saying that the imagery is out of
date and that this intersection has been surveyed.
Change the source tag from nearmap to survey.

Now even though one of the mnappers has a fairly colourful history of edit
wars and non response to polite messages, it may be useful to send both of
them a message pointing out that you have actually surveyed the area and
that the Bing imagery is out of date. You could send links to the Google
map sattelite view that shows the new layout and also the Google street
view that shows the old layout.

I guess that it's possible (but not likely) that the local council have
decided that what they originally had was better and have resealed the
parts that were removed.  You could check whether the latest mapper
actually surveyed it or just traced it from imagery.
I also think it would be nice if all edit software flashed up a warning
(once per session) if you change an object that has a survey tag. This
warning would disappear on the next click but may serve to give the mapper
second thoughts as to whether his changes are for the better or not.

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

Re: [talk-au] Openstreetmap Quality Issues

2013-10-21 Thread stev391

G'day Neil,

Steve, aka Steve91 here, if I have been one of the mappers that have caused 
issues with this intersection I apologies.

As for the source of nearmap, it must have been a copy and past error, from the 
adjacent section of the road. I use AGRI, Bing sat images and survey for areas 
already mapped. The history of the some sections of the offramp show the 
nearmap as a source tag going back to 10/05/10.

The intersection in question I do remember having a look at, but only for 
routing issues due to: disconnected ways, incorrect one-way road leading to 
islands, duplicate ways etc. (i.e. trying to improve the quality of the map, as 
per the comment on the changeset). I identify items for attention via OSM 
Inspector or the validator in JOSM. I don't believe I added the ways. It 
appears that I changed the 2 ways in question from 'track' to tertiary and may 
have reconnected one end of them. 

If the intersection has been remodelled, as per the google earth imagery, then 
the sections of roads should not exist as 'track' and the ways should be 
removed. Also the onramp that is one way should be one way through the entire 
section, not have one way followed by bi-directional followed by one way.

I have no issues with you reverting the changes I made to the intersection, as 
long as the traffic routing is consistent along the ways.

Regards
Steve.

- Original Message -
From: Neil Penman
Sent: 10/22/13 12:10 PM
To: Nick Hocking
Subject: Re: [talk-au] Openstreetmap Quality Issues

Hi Nick,
Yep thats a good idea to add the survey tag. Interestingly the ways did not not 
have a source tag up until jan 2013 however Steve91 added the source of Nearmap 
then. Which I wasn't aware we still had access to.
I'll be heading past the intersection later this week and will check it out.

regards
Neil

On Tue, Oct 22, 2013 at 11:30 AM, Nick Hocking  nick.hock...@gmail.com  wrote:
Hi Neil,

I think the way to get this fixed permanently could be...
Fix it one more time, re-add the note saying that the imagery is out of date 
and that this intersection has been surveyed.
Change the source tag from nearmap to survey.
Now even though one of the mnappers has a fairly colourful history of edit wars 
and non response to polite messages, it may be useful to send both of them a 
message pointing out that you have actually surveyed the area and that the Bing 
imagery is out of date. You could send links to the Google map sattelite view 
that shows the new layout and also the Google street view that shows the old 
layout.
I guess that it's possible (but not likely) that the local council have decided 
that what they originally had was better and have resealed the parts that were 
removed. You could check whether the latest mapper actually surveyed it or just 
traced it from imagery.

I also think it would be nice if all edit software flashed up a warning (once 
per session) if you change an object that has a survey tag. This warning 
would disappear on the next click but may serve to give the mapper second 
thoughts as to whether his changes are for the better or not.

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



--

Smap Consulting  http://smap.com.au/ | Mobile Data Collection Solutions
Application Developer -  minqiang.hu...@gmail.com 
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959
Blog: http://blog.smap.com.au http://smap.com.au/blog
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Openstreetmap Quality Issues

2013-10-21 Thread Neil Penman

Hi Steve,

I left those track sections where the old off ramps were as they still
existed although they have been blocked off at both ends. I think I marked
those with bollards.  The only current access between Diggers Way and the
old Calder is a T junction on the East side.  I'd be surprised if I left
routing issues there though its possible I guess.  All the rest of the
tracks / road segments should have been in accessible.

I just made the change and removed completely all of those old road
fragments as you suggested.  This weekend I will go past with a GPS and get
the correct position of the T junction.

regards

Neil


On Tue, Oct 22, 2013 at 2:22 PM, stev...@email.com wrote:

 G'day Neil,

 Steve, aka Steve91 here, if I have been one of the mappers that have
 caused issues with this intersection I apologies.

 As for the source of nearmap, it must have been a copy and past error,
 from the adjacent section of the road.  I use AGRI, Bing sat images and
 survey for areas already mapped.  The history of the some sections of the
 offramp show the nearmap as a source tag going back to 10/05/10.

 The intersection in question I do remember having a look at, but only for
 routing issues due to: disconnected ways, incorrect one-way road leading to
 islands, duplicate ways etc. (i.e. trying to improve the quality of the
 map, as per the comment on the changeset). I identify items for attention
 via OSM Inspector or the validator in JOSM.  I don't believe I added the
 ways. It appears that I changed the 2 ways in question from 'track' to
 tertiary and may have reconnected one end of them.

 If the intersection has been remodelled, as per the google earth imagery,
 then the sections of roads should not exist as 'track' and the ways should
 be removed. Also the onramp that is one way should be one way through the
 entire section, not have one way followed by bi-directional followed by one
 way.

 I have no issues with you reverting the changes I made to the
 intersection, as long as the traffic routing is consistent along the ways.

 Regards
 Steve.





 - Original Message -

 From: Neil Penman

 Sent: 10/22/13 12:10 PM

 To: Nick Hocking

 Subject: Re: [talk-au] Openstreetmap Quality Issues

 Hi Nick,

 Yep thats a good idea to add the survey tag. Interestingly the ways did
 not not have a source tag up until jan 2013 however Steve91 added the
 source of Nearmap then.  Which I wasn't aware we still had access to.

 I'll be heading past the intersection later this week and will check it
 out.

 regards

 Neil

 On Tue, Oct 22, 2013 at 11:30 AM, Nick Hocking nick.hock...@gmail.comwrote:

 Hi Neil,
 I think the way to get this fixed permanently could be...

 Fix it one more time, re-add the note saying that the imagery is out of
 date and that this intersection has been surveyed.
 Change the source tag from nearmap to survey.

 Now even though one of the mnappers has a fairly colourful history of
 edit wars and non response to polite messages, it may be useful to send
 both of them a message pointing out that you have actually surveyed the
 area and that the Bing imagery is out of date. You could send links to the
 Google map sattelite view that shows the new layout and also the Google
 street view that shows the old layout.

 I guess that it's possible (but not likely) that the local council have
 decided that what they originally had was better and have resealed the
 parts that were removed.  You could check whether the latest mapper
 actually surveyed it or just traced it from imagery.
 I also think it would be nice if all edit software flashed up a warning
 (once per session) if you change an object that has a survey tag. This
 warning would disappear on the next click but may serve to give the mapper
 second thoughts as to whether his changes are for the better or not.

 Nick

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





 --

 Smap Consulting  http://smap.com.au/| Mobile Data Collection Solutions
 Application Developer - neilpen...@gmail.com minqiang.hu...@gmail.com
 Twitter: @dgmsot
 Skype: ianaf4you
 Phone: +61 402 975 959
 Blog: http://blog.smap.com.au http://smap.com.au/blog










-- 

Smap Consulting  http://smap.com.au/| Mobile Data Collection Solutions
Application Developer - neilpen...@gmail.com minqiang.hu...@gmail.com
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959
Blog: http://blog.smap.com.au http://smap.com.au/blog
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Openstreetmap Quality Issues

2013-10-21 Thread Neil Penman

Just noticed the Satellite imagery has been updated.  There does seem to be
some kind of road being set up on the left side of the old calder as well
now.  I'll check that out at the weekend too.


On Tue, Oct 22, 2013 at 2:22 PM, stev...@email.com wrote:

 G'day Neil,

 Steve, aka Steve91 here, if I have been one of the mappers that have
 caused issues with this intersection I apologies.

 As for the source of nearmap, it must have been a copy and past error,
 from the adjacent section of the road.  I use AGRI, Bing sat images and
 survey for areas already mapped.  The history of the some sections of the
 offramp show the nearmap as a source tag going back to 10/05/10.

 The intersection in question I do remember having a look at, but only for
 routing issues due to: disconnected ways, incorrect one-way road leading to
 islands, duplicate ways etc. (i.e. trying to improve the quality of the
 map, as per the comment on the changeset). I identify items for attention
 via OSM Inspector or the validator in JOSM.  I don't believe I added the
 ways. It appears that I changed the 2 ways in question from 'track' to
 tertiary and may have reconnected one end of them.

 If the intersection has been remodelled, as per the google earth imagery,
 then the sections of roads should not exist as 'track' and the ways should
 be removed. Also the onramp that is one way should be one way through the
 entire section, not have one way followed by bi-directional followed by one
 way.

 I have no issues with you reverting the changes I made to the
 intersection, as long as the traffic routing is consistent along the ways.

 Regards
 Steve.





 - Original Message -

 From: Neil Penman

 Sent: 10/22/13 12:10 PM

 To: Nick Hocking

 Subject: Re: [talk-au] Openstreetmap Quality Issues

 Hi Nick,

 Yep thats a good idea to add the survey tag. Interestingly the ways did
 not not have a source tag up until jan 2013 however Steve91 added the
 source of Nearmap then.  Which I wasn't aware we still had access to.

 I'll be heading past the intersection later this week and will check it
 out.

 regards

 Neil

 On Tue, Oct 22, 2013 at 11:30 AM, Nick Hocking nick.hock...@gmail.comwrote:

 Hi Neil,
 I think the way to get this fixed permanently could be...

 Fix it one more time, re-add the note saying that the imagery is out of
 date and that this intersection has been surveyed.
 Change the source tag from nearmap to survey.

 Now even though one of the mnappers has a fairly colourful history of
 edit wars and non response to polite messages, it may be useful to send
 both of them a message pointing out that you have actually surveyed the
 area and that the Bing imagery is out of date. You could send links to the
 Google map sattelite view that shows the new layout and also the Google
 street view that shows the old layout.

 I guess that it's possible (but not likely) that the local council have
 decided that what they originally had was better and have resealed the
 parts that were removed.  You could check whether the latest mapper
 actually surveyed it or just traced it from imagery.
 I also think it would be nice if all edit software flashed up a warning
 (once per session) if you change an object that has a survey tag. This
 warning would disappear on the next click but may serve to give the mapper
 second thoughts as to whether his changes are for the better or not.

 Nick

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





 --

 Smap Consulting  http://smap.com.au/| Mobile Data Collection Solutions
 Application Developer - neilpen...@gmail.com minqiang.hu...@gmail.com
 Twitter: @dgmsot
 Skype: ianaf4you
 Phone: +61 402 975 959
 Blog: http://blog.smap.com.au http://smap.com.au/blog










-- 

Smap Consulting  http://smap.com.au/| Mobile Data Collection Solutions
Application Developer - neilpen...@gmail.com minqiang.hu...@gmail.com
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959
Blog: http://blog.smap.com.au http://smap.com.au/blog
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Openstreetmap Quality Issues

2013-10-21 Thread stev391

Neil,

Once again, sorry if I caused any issues. I try to be careful with my map edits.

The changes that you have made (just now) are more substantial than what was 
there prior to my work on that section of the map. The West side had the 
southbound access left on it and the others on the west side as highway track.

Good luck for the weekend and hopefully once you have surveyed the junction it 
will remain correct...

Steve.
- Original Message -
From: Neil Penman
Sent: 10/22/13 02:38 PM
To: stev...@email.com
Subject: Re: [talk-au] Openstreetmap Quality Issues

Hi Steve,

I left those track sections where the old off ramps were as they still 
existed although they have been blocked off at both ends. I think I marked 
those with bollards. The only current access between Diggers Way and the old 
Calder is a T junction on the East side. I'd be surprised if I left routing 
issues there though its possible I guess. All the rest of the tracks / road 
segments should have been in accessible.

I just made the change and removed completely all of those old road fragments 
as you suggested. This weekend I will go past with a GPS and get the correct 
position of the T junction.

regards

Neil

On Tue, Oct 22, 2013 at 2:22 PM,  stev...@email.com  wrote:G'day Neil,

Steve, aka Steve91 here, if I have been one of the mappers that have caused 
issues with this intersection I apologies.

As for the source of nearmap, it must have been a copy and past error, from the 
adjacent section of the road. I use AGRI, Bing sat images and survey for areas 
already mapped. The history of the some sections of the offramp show the 
nearmap as a source tag going back to 10/05/10.

The intersection in question I do remember having a look at, but only for 
routing issues due to: disconnected ways, incorrect one-way road leading to 
islands, duplicate ways etc. (i.e. trying to improve the quality of the map, as 
per the comment on the changeset). I identify items for attention via OSM 
Inspector or the validator in JOSM. I don't believe I added the ways. It 
appears that I changed the 2 ways in question from 'track' to tertiary and may 
have reconnected one end of them. 

If the intersection has been remodelled, as per the google earth imagery, then 
the sections of roads should not exist as 'track' and the ways should be 
removed. Also the onramp that is one way should be one way through the entire 
section, not have one way followed by bi-directional followed by one way.

I have no issues with you reverting the changes I made to the intersection, as 
long as the traffic routing is consistent along the ways.

Regards
Steve.

- Original Message -
From: Neil Penman
Sent: 10/22/13 12:10 PM
To: Nick Hocking
Subject: Re: [talk-au] Openstreetmap Quality Issues

Hi Nick,
Yep thats a good idea to add the survey tag. Interestingly the ways did not not 
have a source tag up until jan 2013 however Steve91 added the source of Nearmap 
then. Which I wasn't aware we still had access to.
I'll be heading past the intersection later this week and will check it out.

regards
Neil

On Tue, Oct 22, 2013 at 11:30 AM, Nick Hocking  nick.hock...@gmail.com  wrote:
Hi Neil,

I think the way to get this fixed permanently could be...
Fix it one more time, re-add the note saying that the imagery is out of date 
and that this intersection has been surveyed.
Change the source tag from nearmap to survey.
Now even though one of the mnappers has a fairly colourful history of edit wars 
and non response to polite messages, it may be useful to send both of them a 
message pointing out that you have actually surveyed the area and that the Bing 
imagery is out of date. You could send links to the Google map sattelite view 
that shows the new layout and also the Google street view that shows the old 
layout.
I guess that it's possible (but not likely) that the local council have decided 
that what they originally had was better and have resealed the parts that were 
removed. You could check whether the latest mapper actually surveyed it or just 
traced it from imagery.

I also think it would be nice if all edit software flashed up a warning (once 
per session) if you change an object that has a survey tag. This warning 
would disappear on the next click but may serve to give the mapper second 
thoughts as to whether his changes are for the better or not.

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



--

Smap Consulting  http://smap.com.au/ | Mobile Data Collection Solutions
Application Developer -  minqiang.hu...@gmail.com 
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959 tel:%2B61%20402%20975%20959 
Blog: http://blog.smap.com.au http://smap.com.au/blog 

--

Smap Consulting  http://smap.com.au/ | Mobile Data Collection Solutions
Application Developer -  minqiang.hu...@gmail.com 
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959
Blog:

Re: [Talk-de] craft=beekeeper und Direktverkauf



Am 20/ott/2013 um 17:55 schrieb Jörg Frings-Fürst o...@jff-webhosting.net:

 OK, presence_times? Syntax könnte dieselbe sein wie opening_hours
 
 -1
 
 Anzahl taginfo für presence_time(s) 0
 


Witzbold, den Tag hatte ich mir gerade ausgedacht...


 
 Meiner Meinung nach gehören nicht ortsfeste / nicht ständig vorhandenen
 Stände usw. nicht gemappt. Sonst müsste man auch Marktstände,
 Kirmisstände usw. mappen.


ggf. könnte man das dann (wobei es da ggf. besser wäre, mit prefixen zu 
Arbeiten um Verwechslungen auszuschließen ), aber müssen tut man das nicht, 
die Entscheidung liegt beim Mapper. Da gibts m.E. jedenfalls eine Grauzone, wo 
es bei manchen Dingen ggf. Sinn macht und bei anderen weniger

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

Re: [Talk-de] AIO-Ersatz für Garmin?

2013-10-21 Thread Johannes Formann

Moin,

Andreas Tille andr...@an3as.eu wrote:
 Mir ist es wirklich vollkommen schleierhaft, wieso bei einem so starken
 Communityprojekt sich keiner findet, der das von Florian so schön
 formulierte
 
UND EIGENTLICH WOLLTE ICH NUR EINE KARTE
 
 endlich mal zuverlässig umsetzt.

Das Problem ist doch, das es nicht DIE Karte gibt. Ich habe die Pflege der
Radkarte damals übernommen, weil die anderen Radkarten mir einfach nicht
zusagten.
https://launchpad.net/radkarte
Und der Buildprozess dürfte mittlerweile auch so gut funktionieren, dass
Dritte relativ bequem mit nem ant dist selber generieren können, auch für
Gebiete, die ich nicht anbiete.

Eine gemeinsame Plattform hätte für mich auch viele Vorteile, bräuchte
deutlich weniger RAM und Traffik für meinen Server, nur wer soll die
Infrastruktur betreiben?

Grüße 
Johannes


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

Re: [Talk-de] AIO-Ersatz für Garmin?

2013-10-21 Thread Sven Geggus

Johannes Formann johan...@formann.de wrote:

 Eine gemeinsame Plattform hätte für mich auch viele Vorteile, bräuchte
 deutlich weniger RAM und Traffik für meinen Server, nur wer soll die
 Infrastruktur betreiben?

Na ja, den FOSSGIS Server gibt es ja schon. Nicht die schnellste Kiste aber
immerhin.

Wenn ich das richtig sehe laufen dort derzeit die AIO und die Karte von
Computerteddy. Allerdings _ohne_ nennenswerte Synnergieeffekte :(

Gruss

Sven

-- 
We just typed make
(Stephen Lambrigh, Director of Server Product Marketing at Informix
  about porting their Database to Linux)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] craft=beekeeper und Direktverkauf

2013-10-21 Thread Jörg Frings-Fürst

Hallo Nils,

zuerst einmal ich lehne das taggen nicht ab, ich bin nur der Meinung das
das in den besprochenen Fällen nicht sinnvoll ist.

Überlege einmal:

der Stand wurde gemappt. Der Betreiber geht in Urlaub, Stand wird
abgebaut -- nächster Mapper löscht den Stand wieder in OSM.

Zum zweiten sehe ich ein Problem mit der Wartung bzw. den ständig 
aktuell zu haltenen Aktivzeiten.

Und für hier in dem Fall der Imker, was ja IMHO dem Verkauf von 
Honig impliziert, sollte der Imker - Tag reichen. Den Stand wird
man dann schon nicht übersehen. Da kommt mir gerade der Gedanke 
ob das taggen des Standes für den Imker nicht kontraproduktiv ist
- Stand nicht da, oder nicht besetzt -- kein Honig zu verkaufen
obwohl man ja mal hätte klingen können.

Laut[1] gibt es allein in Deutschland ca. 94.000 Imker. Bei OSM[2] 
sind mal gerade 215 weltweit eingetragen.
Bei der Datenbasis macht es keinen Sinn über OSM nach Imkern zu 
suchen.

Gruß Jörg

[1] 
http://www.deutscherimkerbund.de/index.php?die-deutsche-imkerei-auf-einen-blick
[2] http://taginfo.openstreetmap.org/search?q=craft%3Dbeekeeper
 
-- 
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org


Am Sonntag, den 20.10.2013, 20:22 +0200 schrieb pmsg:
 2013/10/20 Jörg Frings-Fürst o...@jff-webhosting.net
 
  Meiner Meinung nach gehören nicht ortsfeste / nicht ständig vorhandenen
  Stände usw. nicht gemappt. Sonst müsste man auch Marktstände,
  Kirmisstände usw. mappen.
 
 Kurze frage zu deiner Ansicht: Der ortsfeste Stand würde zwar nicht das
 ganze Jahr Honig/Erdbeeren/Neuer Wein verkaufen, aber ist das ganze Jahr
 mit einem Schild versehen, das von der Straße aus lesbar ist. Würdest du
 auch ablehnen, dass interessierte Mapper solche Stände taggen würden bzw.
 passende Tags dafür schaffen würden?
 Mir geht es nicht um mobile Marktstände, sondern um solche, die direkt am
 Grundstück des Erzeugers stehen.
 
 Grüße, Nils




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

Re: [Talk-de] craft=beekeeper und Direktverkauf

Am 21. Oktober 2013 14:30 schrieb Jörg Frings-Fürst o...@jff-webhosting.net
:


 Und für hier in dem Fall der Imker, was ja IMHO dem Verkauf von
 Honig impliziert, sollte der Imker - Tag reichen.



mit Implikationen sollte man vorsichtig sein, ich würde wenn es um eine
explizite Verkaufsstelle geht (wie hier ein Verkaufsstand) einen shop-tag
verwenden, und nicht auf Implikationen aus dem craft-tag hoffen, schaden
wird es nichts.



 Den Stand wird
 man dann schon nicht übersehen. Da kommt mir gerade der Gedanke
 ob das taggen des Standes für den Imker nicht kontraproduktiv ist
 - Stand nicht da, oder nicht besetzt -- kein Honig zu verkaufen
 obwohl man ja mal hätte klingen können.



ja, irgendwas kann man immer konstruieren ;-)




 Laut[1] gibt es allein in Deutschland ca. 94.000 Imker. Bei OSM[2]
 sind mal gerade 215 weltweit eingetragen.
 Bei der Datenbasis macht es keinen Sinn über OSM nach Imkern zu
 suchen.



na und? Zum einen reicht es meist schon, ein oder zwei nahegelegene
Resultate zu bekommen (vielleicht hat man ja Glück), und zum anderen hätten
wir überhaupt nicht erst anfangen müssen irgendwas zu mappen, wenn wir so
herangegangen wären ;-)

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

[Talk-it] Renderizzare mappa senza punti di interesse

Salve ho questo problema.Ho realizzato una cartina utilizzando openlayer 2.0
, OSM e ho usato la mappe generate da cloudmadeper personalizzare la
grafica.Il problema è che non vorrei che apparissero alcuni punti di
interesse tipo parcheggi e altre amenity.Ho installato su una distribuzione
Ubuntu 12.04 LTS il modulo apache Mod_tile , Mapnik , osm2pgsql dal momento
che cercando di installare tutto su una Debian avevo parecchi errori di
compilazione.Ora volevo sapere se è possibile , mediante qualche
configurazione su Mod_tile o Mapnik avere la possibilitàdi non renderizzare
automaticamente i punti di interesse.HO trovato questo servizio
https://tiles.mapbox.com/ che genera mappe proprio di questo tipo.Grazie in
anticipo a chi mi può essere di aiuto.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Renderizzare-mappa-senza-punti-di-interesse-tp5782362.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] Renderizzare mappa senza punti di interesse

2013/10/21 akstern ca...@artmediastudio.com:
 HO trovato questo servizio https://tiles.mapbox.com/ che genera mappe
 proprio di questo tipo. Grazie in anticipo a chi mi può essere di aiuto.

quanto è grande la tua area di riferimento? una città, una regione,
tutta l'italia?

hai gia' un tuo stile che vorresti utilizzare?

se sei disposto a fare tu la grafica della mappa, puoi usate tilemill,
da scaricarsi, e non quello online: https://www.mapbox.com/tilemill/

-- 
-S

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

[Talk-it] Richiesta per datalogger

2013-10-21 Thread sabas88

Ciao,
un utente ha chiesto sulla pagina Google+ un consiglio per un datalogger...

Buon giorno
ho guardato un po' nel blog e in giro per la rete ma trovo solo info un po'
datate. Cerco un datalogger gps da portare con me (piccole dimensioni) di
buona qualità precisione/ricezione. Non so a cosa devo stare attento al
momento dell'acquisto (doppia frequenza, canali o chi sa che altro).
Possibilmente una spesa contenuta (nessun miracolo certo).
Inoltre che si interfacci al meglio con sistemi operativi GNU/Linux Debian
- Ubuntu. Se qualcuno mi può aiutare vi ringrazio molto.
Buona navigazione a tutti
Nicola

Consigliate che riporto :-)

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

Re: [Talk-it] Renderizzare mappa senza punti di interesse

Grazie per la risposta e per l' aiuto.
L’ Area di riferimento è una città anche se in prospettiva pensare già ad
regione non è male.
Per quanto riguarda il foglio di stile non mi sono ancora documentato
abbastanza come farlo, ma 
avevo intuito che poteva servire e avevo già scaricato la versione desktop.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Renderizzare-mappa-senza-punti-di-interesse-tp5782362p5782371.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] Richiesta per datalogger

2013-10-21 Thread Fabrizio Tambussa

Io ho un 747A+ e mi trovo benissimo.  Lo trovi su ebay
Ciao
Il 21/ott/2013 13:25 sabas88 saba...@gmail.com ha scritto:

 Ciao,
 un utente ha chiesto sulla pagina Google+ un consiglio per un datalogger...

 Buon giorno
 ho guardato un po' nel blog e in giro per la rete ma trovo solo info un
 po' datate. Cerco un datalogger gps da portare con me (piccole dimensioni)
 di buona qualità precisione/ricezione. Non so a cosa devo stare attento al
 momento dell'acquisto (doppia frequenza, canali o chi sa che altro).
 Possibilmente una spesa contenuta (nessun miracolo certo).
 Inoltre che si interfacci al meglio con sistemi operativi GNU/Linux Debian
 - Ubuntu. Se qualcuno mi può aiutare vi ringrazio molto.
 Buona navigazione a tutti
 Nicola

 Consigliate che riporto :-)

 Grazie,
 Stefano

 ___
 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] Renderizzare mappa senza punti di interesse

2013-10-21 Thread Cristian Consonni

Il 21 ottobre 2013 13:26, akstern ca...@artmediastudio.com ha scritto:
 Per quanto riguarda il foglio di stile non mi sono ancora documentato
 abbastanza come farlo, ma
 avevo intuito che poteva servire e avevo già scaricato la versione desktop.

Credo che Simone si stesse riferendo in particolare a CartoCSS, che
credo sia proprio quello che ti serve.
Vedi:
* https://www.mapbox.com/tilemill/docs/manual/carto/
* https://www.mapbox.com/tilemill/docs/guides/advanced-map-design/

Ciao,

C

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

Re: [Talk-it] Richiesta per datalogger

2013/10/21 Fabrizio Tambussa ftambu...@gmail.com

 Io ho un 747A+ e mi trovo benissimo.  Lo trovi su ebay



anch'io connosco quel tipo e ricordo che era buono, però è molto vecchio,
non c'è un modello attuale migliore, che ne so, con GPS e GLOSNAS insieme?

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

Re: [Talk-it] Renderizzare mappa senza punti di interesse

Se ho capito bene con CartoCSS posso creare uno stile che mi permette anche
di non fare renderizzare i poi tipo amenity anche sul mio server oltre che
su mapbox.
Sbirciando sui file di configurazione di mapnik ho visto che viene applicato
uno stile di default.
In teoria quindi faccio questo style e poi sostituisco lo stile di default .
Corretto ?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Renderizzare-mappa-senza-punti-di-interesse-tp5782362p5782380.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] Renderizzare mappa senza punti di interesse

2013/10/21 Cristian Consonni kikkocrist...@gmail.com:
 Credo che Simone si stesse riferendo in particolare a CartoCSS, che
 credo sia proprio quello che ti serve.
 Vedi:
 * https://www.mapbox.com/tilemill/docs/manual/carto/
 * https://www.mapbox.com/tilemill/docs/guides/advanced-map-design/

se decidi di usare tilemill esistono alcuni stili disponibili in modo
aperto, fra questi lo stile bright di mapbox, che di cui ti metto il
link di seguito https://github.com/mapbox/osm-bright e
https://github.com/mapbox/tilemill_examples

-- 
-S

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

Re: [Talk-it] Renderizzare mappa senza punti di interesse

Grazie per i link.
Per applicare uno stile alla mia installazione di mapnik avete qualche link
con esempio pratico .
Io ho installato mapnik seguendo il tutorial all' indirizzo 
http://seshagiriprabhu.wordpress.com/2013/07/21/building-an-openstreetmap-tile-server-on-ubuntu-12-04-lts/
in cui installando libapache2-mod-tile viene installato anche mapnik.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Renderizzare-mappa-senza-punti-di-interesse-tp5782362p5782385.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] Renderizzare mappa senza punti di interesse

2013/10/21 akstern ca...@artmediastudio.com

 Se ho capito bene con CartoCSS posso creare uno stile che mi permette anche
 di non fare renderizzare i poi tipo amenity anche sul mio server oltre che
 su mapbox.
 Sbirciando sui file di configurazione di mapnik ho visto che viene
 applicato
 uno stile di default.
 In teoria quindi faccio questo style e poi sostituisco lo stile di default
 .
 Corretto ?



innanzitutto capire quale renderer. Ci sono alcuni, il vechio osmarender
per certi compiti non è male (non richiede un db), come anche su Windows
c'è Kosmos/Maperitive http://maperitive.net/

E ci sono i mapservers (geoserver / mapserver). Poi, se vuoi partire dallo
stile attuale sul sito osm.org c'è Mapnik.
Mapnik è anche consigliato perché è veloce e carino, ed è in forte sviluppo.

Oltre a mapnik ti serve osm2pgsql per caricare i tuoi dati in un database
postgres/postgis (non strettamente necessario ma consigliabile), quindi
anche uno stile default.style per osm2pgsql. Non è del tutto triviale
crearsi questo stack, perché ci sono parecchie dipendenze, e un po' di
configurazione.

Poi ti serve uno stile per mapnik, fatto in XML o cartocss o mapcss ;-)
Le ultime due richiedono un precompilatore che trasforma lo stile in un XML.

Se vuoi lavorare con cartocss ti consiglio anch'io tilemill.

Un ottimo punto di partenza (oltre al sito di Mapnik) è il wiki di osm.

Poi se vuoi renderizzare tiles in automatico ti serve anche apache2,
mod_tile e renderd o tirex. Anche questo è un'ulteriore complicazione, che
non devi per forza fare (puoi anche utlizzare un script come
generate_tiles.py che genera i tiles per una certa zona, oppure un imagine
grande).

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

Re: [Talk-it] Renderizzare mappa senza punti di interesse

2013/10/21 akstern ca...@artmediastudio.com:
 Grazie per i link.
 Per applicare uno stile alla mia installazione di mapnik avete qualche link
 con esempio pratico .
 Io ho installato mapnik seguendo il tutorial all' indirizzo
 http://seshagiriprabhu.wordpress.com/2013/07/21/building-an-openstreetmap-tile-server-on-ubuntu-12-04-lts/
 in cui installando libapache2-mod-tile viene installato anche mapnik.

https://github.com/openstreetmap/mapnik-stylesheets
questo è lo stile che trovi su osm.org. sicuramente complesso da
maneggiare visto il volume.

secondo me faresti meglio a partire da tilemill che da risultati
immediati e ti permette di impratichirti con gli stili.
http://gis.stackexchange.com/questions/62348/is-there-a-carto-css-gallery-which-also-contains-code

-- 
-S

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

Re: [Talk-it] Vela percorso bike

2013/10/20 Michele Malfatti michele.malfa...@gmail.com

 Questa è una vela. Porzione ti mappa che corrisponde al tratto di percorso
 che fa da questa vela alla progressiva. Mich74


per me sarebbe tourism=information, information=board board_type=map
operator=...

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

Re: [Talk-it] Renderizzare mappa senza punti di interesse

2013/10/21 Simone Cortesi sim...@cortesi.com

 https://github.com/openstreetmap/mapnik-stylesheets
 questo è lo stile che trovi su osm.org. sicuramente complesso da
 maneggiare visto il volume.



pensavo fosse questo: https://github.com/gravitystorm/openstreetmap-carto/
E' in carto quindi in teoria puoi lavorare live con tilemill (penso che
non funzionerà per motivo di shapefiles ecc. che alla fine saranno troppo
grandi, ma dipende dal sistema (memoria e dischi).

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

Re: [Talk-it] Vela percorso bike

2013-10-21 Thread Volker Schmidt

2013/10/21 Martin Koppenhoefer dieterdre...@gmail.com

 per me sarebbe tourism=information, information=board board_type=map
 operator=...

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

Re: [Talk-it] Renderizzare mappa senza punti di interesse

Guardando un po' in giro avevo visto che la combinazione che va per la
maggiore eramapnik,osm2pgsql ,mod_tile Ho provato ad installare i moduli per
la distribuzione debian ma non esiste mod_tile .Ho tentato di installare da
sorgente ma fallisce a causa di errori di compilazione .Quindi sono passato
a Ubuntu ed installando semplicemente mod_tile ha installato il resto come
dipendenze.Ora però tu mi dici che devo applicare uno stile sia a Mapnik che
a osm2pgsql .Alla fine dell' installazione del modulo ho lanciato il
comandosudo -u www-data osm2pgsql -C 16000 --slim --number-processes 8
india-latest.osm.pbfe ci ha messo 4 ore per inizializzare di db.Devo
rilanciare tutto oppure è sufficiente rilanciare sudo /etc/init.d/renderd
restart ?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Renderizzare-mappa-senza-punti-di-interesse-tp5782362p5782391.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] Renderizzare mappa senza punti di interesse

Grazie Simone seguirò il tuo consiglio .
Ma secondo te è sufficiente agire sullo stile di di mapnik per eliminare la
rendrizzazione dei poi in modo da sostituirli con i miei tramite openlayer ?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Renderizzare-mappa-senza-punti-di-interesse-tp5782362p5782392.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] Renderizzare mappa senza punti di interesse

2013/10/21 akstern ca...@artmediastudio.com:
 Grazie Simone seguirò il tuo consiglio .
 Ma secondo te è sufficiente agire sullo stile di di mapnik per eliminare la
 rendrizzazione dei poi in modo da sostituirli con i miei tramite openlayer ?

per questo devi agire cosi':
eliminare dallo stile scelto i POI
effettuare il rendering dell'area di interesse
caricare in openlayers (probabilmente in maniera dinamica) i POI e
visualizzarli come vuoi tu


PS: io preferisco leafletjs al posto di openlayers. che fra l'altro ha
gia' un plugin per fare query ai POI.

-- 
-S

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

Re: [Talk-it] Renderizzare mappa senza punti di interesse

2013/10/21 akstern ca...@artmediastudio.com

 Ora però tu mi dici che devo applicare uno stile sia a Mapnik che a
 osm2pgsql . Alla fine dell' installazione del modulo ho lanciato il comando
 sudo -u www-data osm2pgsql -C 16000 --slim --number-processes 8
 india-latest.osm.pbf e ci ha messo 4 ore per inizializzare di db. Devo
 rilanciare tutto oppure è sufficiente rilanciare sudo /etc/init.d/renderd
 restart ?


lo stile per osm2pgsql definisce cosa ti finisce nel tuo db, lo devi
aggiustare prima di caricare i dati nel db, col tuo commando hai usato lo
stile di default, che forse ti va anche bene, lo guarderei prima di
interrompere il caricamento. Comunque con solo un paese non devi aspettare
tantissimo (appunto 4 ore), se poi scopri dopo che ti manca qualcosa lo
puoi fare sempre. Anche hstore è un'opzione da guardarsi, è utile se non
sei deciso su quali tags ti servono. C'è docu per tutto nel wiki (anche per
osm2pgsql).

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

Re: [Talk-it] Richiesta per datalogger

2013-10-21 Thread girarsi_liste

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Il 21/10/2013 15:16, Martin Koppenhoefer ha scritto:

 anch'io connosco quel tipo e ricordo che era buono, però è molto
 vecchio, non c'è un modello attuale migliore, che ne so, con GPS e
 GLOSNAS insieme?
 
 ciao, Martin
 

Io ho un Garmin Etrex 30, pagato 200€ presso Lina24 (+spese corriere),
erò non so se è il budget richiesto, ad ogni modo registra sia GPS
oppure GPS +GLONASS, ed ha pure il SR a scelta, come il nostro WGS84.

Come riferimento h visto questa recensione per il miglior uso (per
modo di dire).

http://cuneotrekking.com/2013/04/23/garmin-etrex-30-la-recensione-completa/


Ha pure la bussola, ma sarà mia impressione, penso disturbi il
segnale, difatti disattivandola, mi è capitato a cielo aperto di
trovarmi anche 1 Mt di precisione (parametro presente nel Garmin, non
so se affidabile però!).

Ci si può caricare anche una mappa openstreetmap nella scheda microsd,
ed infatti io l'ho installata, anche se non la uso, però è possibile.

E può anche scegliere il tipo di misurazione dell'altimetro, che però
non so consigliare, prechè non conosco bene i parametri.




- -- 
Simone Girardelli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iF4EAREIAAYFAlJlTgEACgkQoVS0hKoD3PNELgD/SPbHw/2xTeQ0CdzJOF8lcRRR
DuuFJ7lPtIyhigxl66sA/2Ih9b8KIpI3EH0reCa+COgi/hCWz760essiLPmKI2Kz
=rZ0i
-END PGP SIGNATURE-

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

[Talk-it] Way tra scalinate

2013-10-21 Thread Fabrizio Tambussa

Ciao a tutti,
sto mappando il centro di Matera, la famosa zona dei Sassi. Continuo a
trovare delle porzioni di vie comprese tra 2 scalinate.  Ovvero scendo la
scalinata, percorro 100 metri di strada lastricata e abbastanza ampia, poi
incontro un'altra scalinata.

 Come classifico questa porzione di 100 metri di via? Io penserei a
pedestrian, visto che non posso ragionevolmente salire/scendere le scale
con la moto o con la bici.

Faccio bene?

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

Re: [Talk-it] Way tra scalinate

2013-10-21 Thread girarsi_liste

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Il 21/10/2013 18:30, Fabrizio Tambussa ha scritto:
 Ciao a tutti, sto mappando il centro di Matera, la famosa zona dei
 Sassi. Continuo a trovare delle porzioni di vie comprese tra 2
 scalinate.  Ovvero scendo la scalinata, percorro 100 metri di
 strada lastricata e abbastanza ampia, poi incontro un'altra
 scalinata.
 
 Come classifico questa porzione di 100 metri di via? Io penserei a 
 pedestrian, visto che non posso ragionevolmente salire/scendere le
 scale con la moto o con la bici.
 
 Faccio bene?
 

Per la bici non è detto. dipende dagli
scalinioltrechè dai temerari...

Detto questo, la way la vedo service, presumo che ci sia chi ci abita
nel mezzo, e un nodo per ogni scalino, con specifica:
highway=service (sulla way tra scala e altra)
service=alley (sulla way tra scala e altra)
highway=steps (sul nodo/scalino)
steps=1 (sul nodo/scalino)
foot=designated (sulla way tra scala e altra)
bicycle=permissive (?) (sulla way tra scala e altra)
mothor_veichle=no (sulla way tra scala e altra e sicuramente cè
presenza di qualche cartello di divieto, in quel caso và taggato con
un nodo apposito.)

poi ce un'accesso come?

access=*

surface=cobblestone?

ci sono limitazioni di orario o di qualche tipo?

è zona storica? penso di sì, quindi:

historic=monument (?)




- -- 
Simone Girardelli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iF4EAREIAAYFAlJlXy4ACgkQoVS0hKoD3POLfQD/d73x1eDchOK26/vvTVWe4qof
ML43ZZ5WAZFiA487EuUBAIdDkG6DId5W2cZsOoSAAl4ArNH9rdW9omEqqgvYhNad
=mHVH
-END PGP SIGNATURE-

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

Re: [Talk-it] Way tra scalinate

2013-10-21 Thread Andrea Musuruane

Io metterei footway.

Ciao,

Andrea
 Il 21/ott/2013 18:31 Fabrizio Tambussa ftambu...@gmail.com ha scritto:

 Ciao a tutti,
 sto mappando il centro di Matera, la famosa zona dei Sassi. Continuo a
 trovare delle porzioni di vie comprese tra 2 scalinate.  Ovvero scendo la
 scalinata, percorro 100 metri di strada lastricata e abbastanza ampia, poi
 incontro un'altra scalinata.

  Come classifico questa porzione di 100 metri di via? Io penserei a
 pedestrian, visto che non posso ragionevolmente salire/scendere le scale
 con la moto o con la bici.

 Faccio bene?

 Saluti
 Fabrizio sbiribizio

 ___
 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] Vela percorso bike

2013-10-21 Thread Luca Delucchi

Il giorno 21/ott/2013 16:10, Martin Koppenhoefer dieterdre...@gmail.com
ha scritto:


 per me sarebbe tourism=information, information=board board_type=map
operator=...


+1

 ciao,
 Martin


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

[Talk-it] Relazione fiume Brenta da correggere.

2013-10-21 Thread girarsi_liste

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chiedo gentilmente, a chi ha pratica di relazioni su grande scala
(regionale probabile), se per cortesia può controllare le relazioni
del fiume Brenta in trentino e delle prealpi in generale sempre lì, in
quanto, cliccandoci sopra mi dà due relazioni non corrispondenti al
reale, ovvero:

1- Corso d'acqua (waterway) (Brenta, 7 membri, incompleto)--
main_stream--1

2- multi-poligono (Dolomiti di Fiemme, 77 membri, incompleto)--
outer-- 31

3- multi-poligono (Prealpi vicentine, 21 membri, incompleto)--
outer-- 16

Quanto spiegato in wikipedia [0] mi pare sufficiente, sopratutto il
disegno sulla destra 8vedi Vizentiner Alpen e Fleimstaler Alpen), la
seconda o la terza relazione dev'essere inner od outer, non conosco
ancora bene la differenza, anche se ho letto la wiki, ma dovendo
gestire la cosa su un'ampia zona, con josm non ho possibilità di
farlo, o comunque dovrei scaricarmi parecchie aree prima di farci il
giro.

Grazie a chi si interesserà e correggerà.



[0] http://it.wikipedia.org/wiki/Prealpi_Vicentine



- -- 
Simone Girardelli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iF4EAREIAAYFAlJlhPoACgkQoVS0hKoD3POpEQD+OvYXW5MAaBEq92VKYdvG/Swm
r9zYgsB47TIZWVVlhDgA+gPnYFa4f78iWPNYHDK1so5q8DMaNTdEJEa2zaoiLJ4A
=9si2
-END PGP SIGNATURE-

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

Re: [Talk-it] Domande varie su come taggare (residence, sottopassi metropolitana, negozi, public_transport, targhe memoria, ecc.)

2013-10-21 Thread Any File

Innanzitutto grazie Martin,

2013/10/20 Martin Koppenhoefer dieterdre...@gmail.com:

 2013/10/20 Any File anysomef...@gmail.com

 * Sottopassi metropolitana. C'è qualche tag specifico per indicare i
 percorsi

 E c'è un modo
 per indicare che non sono sempre aperti, ma che sono aperti solo
 durante l'orario
 di apertura della metropolitana

 opening_hours oppure conditional access

Il problema è che non è così facile capire l'orario, cambi in base al
giorno ed in base
alla stazione.



 E per negozi
 specializzati in alcuni articoli particolari per cucina (ho trovato un
 negozio che vende solo articoli
 per cake design, devo taggarlo come negozio per casalinghi?)



 direi se specializzato in cake design si merita un tag apposito. Per
 casalinghi che tag usi?

Non mi ricordo di aver taggato negozi di casalinghi (ne conoscevo alcuni, alcuni
vicinissimi a casa mia, ma sono tutti chiusi da tempo, sostituiti da minmarket
gestiti da cinesi o cose simili).

Per i casalinghi avrei trovato

shop=houseware

http://wiki.openstreetmap.org/wiki/Tag:shop%3Dhouseware

(che punta sul fatto che l'articolo venduta sia piccolo)

oppure c'è

shop=kitchen

http://wiki.openstreetmap.org/wiki/Tag:shop%3Dkitchen

che non ho ben capito cosa sia ...



 * Come taggare targhe commemorative su edifici, tipo Qui visse tal
 dei tali o In questa nacque tal dei tali.


 si, anch'io uso historic=memorial,
 C'è anche un progetto apposto http://openplaques.org

Adesso ci guardo. Ma se il progetto è interessante allora sarebbe
utile se ci fosse
un modo per collegare i due dati.

ciao

AnyFile

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

Re: [Talk-it] Way tra scalinate



 Am 21/ott/2013 um 18:30 schrieb Fabrizio Tambussa ftambu...@gmail.com:
 
  Come classifico questa porzione di 100 metri di via? Io penserei a 
 pedestrian, visto che non posso ragionevolmente salire/scendere le scale con 
 la moto o con la bici.
 
 Faccio bene?


se si accede solo tramite scale metto anch'io footway o quando è veramente 
largo pedestrian. 

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

Re: [Talk-it] Domande varie su come taggare (residence, sottopassi metropolitana, negozi, public_transport, targhe memoria, ecc.)