Re: [OSM-talk-nl] fuel;parking

[Milo van der Linden]

Hey! Lief blijven tegen elkaar hé ;-)

Voor 99,9% van de gevallen voel ik voor hetgeen Stefan beschrijft. 
Duplicate values er uit laten vissen en voordragen voor verandering. Dit 
geld voor alle key-value pairs die van invloed zijn op de rendering

In het geval van "name" stuit je op iets heel bijzonders dat eigenlijk 
een structurele database wijziging met zich mee draagt... Feitelijk zou 
ik het zelf het mooiste vinden als de name= tags worden losgeweekt van 
alle anderen en een aparte tabel zouden krijgen die het ook mogelijk 
maakt om gelocalized te worden:
b.v.:

key| value| lang

of in tabellen per taal.

Ik vind persoonlijk de ; : ook een beetje eng.


Stefan de Konink wrote:
> Lambertus wrote:
>   
>> Stefan de Konink wrote:
>> 
>>> On Mon, 23 Feb 2009, Lambertus wrote:
>>>
>>>   
 Ik denk dat je met unieke key/value combinaties veel problemen gaat
 krijgen. Stel je voor dat er meerdere name tags worden toegevoegd
 bijvoorbeeld om de friese en NL naam van een stad te taggen:
 name=Sneek
 name=Snits

 Dit is natuurlijk fout getagd, het zou moeten zijn:
 name=Sneek
 name:frl=Snits

 Mappers zijn geen computers en niemand die de fout snel opmerkt als het
 databasetechnisch mag, want key/value zijn verschillend immers. Ik denk
 dat daarom unieke keys in OSM gebruikt worden.
 
>>> Dat los je op door expliet een tooltje te draaien, zoals dat nu ook
>>> gebeurt.
>>>
>>>   
>> Maar technisch is het dus niet fout en moet je weer tools gebruiken om 
>> deze niet-foute data te corrigerennaar wat eigenlijk? Welke van de 
>> twee name keys is goed voor een node of way?
>>
>> name=Sneek
>> name=Snits
>> 
>
> Dat moet je aan de persoon vragen die *duplicate names* controleert. in 
> 99% van de gevallen gaat het over amenity.
>
>   
>> is voor een check programma niks anders dan:
>>
>> amenity=fuel
>> amenity=parking
>>
>> of
>>
>> highway=primary
>> highway=cycleway
>>
>> Bepaal nu maar eens welke van bovenstaande combinaties fout is.
>> 
>
> Dat is het wel, want daarop kun je heuristiek uitvoeren. Immers, welke 
> tags kunnen wel meerdere keren voorkomen en welke niet. Je hebt het 
> probleem nu *taal* (XML) onafhankelijk gemaakt. Dus het tooltje gaat 
> controleren op ambigue zaken... lijkt me totaal niet spannend, en kun je 
> met een standaard XQuery uitvoeren. In tegenstelling tot het ; geneuzel.
>
>
>   >>> De dubbele value fuel;parking zou overigens door een renderer prima
>   
 opgelost kunnen worden door twee symbolen naast elkaar te tekenen i.p.v.
 bovenop elkaar.
 
>>> Dan ga je er vanuit dat de renderer ; als scheidingsteken implementeert.
>>> Die aanname is niet XML, dus per definitie een uitbreiding op de
>>> standaard, die zo nooit is bedoeld.
>>>
>>>   
>> Moah, in XML mag je van alles als data invoeren en een scheidingsteken 
>> in de data heeft niks met XML standaarden van doen. Maar het is geen 
>> nette oplossing maar wel een werkbare conventie (die iedereen leert 
>> kennen net als alle veel gebruikt keys of values in de map_features 
>> pagina).
>>
>> Dus ik vind het afdwingen van een unieke key met mogelijke value 'hack' 
>> minder erg dan een datamodel waarvan je onmogelijk kan zeggen of de data 
>>   ook maar in de verte iets zinnigs bevat.
>> 
>
> Je drogreden slaat hier kant noch wal, omdat momenteel zelfs de 
> renderers niet om kunnen gaan met ; in de key.
>
>
> Stefan
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
>
>   


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

Re: [OSM-talk-nl] fuel;parking

[Stefan de Konink]

Lambertus wrote:
> Stefan de Konink wrote:
>> On Mon, 23 Feb 2009, Lambertus wrote:
>>
>>> Ik denk dat je met unieke key/value combinaties veel problemen gaat
>>> krijgen. Stel je voor dat er meerdere name tags worden toegevoegd
>>> bijvoorbeeld om de friese en NL naam van een stad te taggen:
>>> name=Sneek
>>> name=Snits
>>>
>>> Dit is natuurlijk fout getagd, het zou moeten zijn:
>>> name=Sneek
>>> name:frl=Snits
>>>
>>> Mappers zijn geen computers en niemand die de fout snel opmerkt als het
>>> databasetechnisch mag, want key/value zijn verschillend immers. Ik denk
>>> dat daarom unieke keys in OSM gebruikt worden.
>> Dat los je op door expliet een tooltje te draaien, zoals dat nu ook
>> gebeurt.
>>
> Maar technisch is het dus niet fout en moet je weer tools gebruiken om 
> deze niet-foute data te corrigerennaar wat eigenlijk? Welke van de 
> twee name keys is goed voor een node of way?
> 
> name=Sneek
> name=Snits

Dat moet je aan de persoon vragen die *duplicate names* controleert. in 
99% van de gevallen gaat het over amenity.

> is voor een check programma niks anders dan:
> 
> amenity=fuel
> amenity=parking
> 
> of
> 
> highway=primary
> highway=cycleway
> 
> Bepaal nu maar eens welke van bovenstaande combinaties fout is.

Dat is het wel, want daarop kun je heuristiek uitvoeren. Immers, welke 
tags kunnen wel meerdere keren voorkomen en welke niet. Je hebt het 
probleem nu *taal* (XML) onafhankelijk gemaakt. Dus het tooltje gaat 
controleren op ambigue zaken... lijkt me totaal niet spannend, en kun je 
met een standaard XQuery uitvoeren. In tegenstelling tot het ; geneuzel.


  >>> De dubbele value fuel;parking zou overigens door een renderer prima
>>> opgelost kunnen worden door twee symbolen naast elkaar te tekenen i.p.v.
>>> bovenop elkaar.
>> Dan ga je er vanuit dat de renderer ; als scheidingsteken implementeert.
>> Die aanname is niet XML, dus per definitie een uitbreiding op de
>> standaard, die zo nooit is bedoeld.
>>
> Moah, in XML mag je van alles als data invoeren en een scheidingsteken 
> in de data heeft niks met XML standaarden van doen. Maar het is geen 
> nette oplossing maar wel een werkbare conventie (die iedereen leert 
> kennen net als alle veel gebruikt keys of values in de map_features 
> pagina).
> 
> Dus ik vind het afdwingen van een unieke key met mogelijke value 'hack' 
> minder erg dan een datamodel waarvan je onmogelijk kan zeggen of de data 
>   ook maar in de verte iets zinnigs bevat.

Je drogreden slaat hier kant noch wal, omdat momenteel zelfs de 
renderers niet om kunnen gaan met ; in de key.


Stefan

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

Re: [OSM-talk-nl] fuel;parking

[Lambertus]

Stefan de Konink wrote:
> On Mon, 23 Feb 2009, Lambertus wrote:
> 
>> Ik denk dat je met unieke key/value combinaties veel problemen gaat
>> krijgen. Stel je voor dat er meerdere name tags worden toegevoegd
>> bijvoorbeeld om de friese en NL naam van een stad te taggen:
>> name=Sneek
>> name=Snits
>>
>> Dit is natuurlijk fout getagd, het zou moeten zijn:
>> name=Sneek
>> name:frl=Snits
>>
>> Mappers zijn geen computers en niemand die de fout snel opmerkt als het
>> databasetechnisch mag, want key/value zijn verschillend immers. Ik denk
>> dat daarom unieke keys in OSM gebruikt worden.
> 
> Dat los je op door expliet een tooltje te draaien, zoals dat nu ook
> gebeurt.
> 
Maar technisch is het dus niet fout en moet je weer tools gebruiken om 
deze niet-foute data te corrigerennaar wat eigenlijk? Welke van de 
twee name keys is goed voor een node of way?

name=Sneek
name=Snits

is voor een check programma niks anders dan:

amenity=fuel
amenity=parking

of

highway=primary
highway=cycleway

Bepaal nu maar eens welke van bovenstaande combinaties fout is.

>> De dubbele value fuel;parking zou overigens door een renderer prima
>> opgelost kunnen worden door twee symbolen naast elkaar te tekenen i.p.v.
>> bovenop elkaar.
> 
> Dan ga je er vanuit dat de renderer ; als scheidingsteken implementeert.
> Die aanname is niet XML, dus per definitie een uitbreiding op de
> standaard, die zo nooit is bedoeld.
> 
Moah, in XML mag je van alles als data invoeren en een scheidingsteken 
in de data heeft niks met XML standaarden van doen. Maar het is geen 
nette oplossing maar wel een werkbare conventie (die iedereen leert 
kennen net als alle veel gebruikt keys of values in de map_features 
pagina).

Dus ik vind het afdwingen van een unieke key met mogelijke value 'hack' 
minder erg dan een datamodel waarvan je onmogelijk kan zeggen of de data 
  ook maar in de verte iets zinnigs bevat.


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

Re: [OSM-talk-nl] fuel;parking

[Stefan de Konink]

On Mon, 23 Feb 2009, Lambertus wrote:

> Ik denk dat je met unieke key/value combinaties veel problemen gaat
> krijgen. Stel je voor dat er meerdere name tags worden toegevoegd
> bijvoorbeeld om de friese en NL naam van een stad te taggen:
> name=Sneek
> name=Snits
>
> Dit is natuurlijk fout getagd, het zou moeten zijn:
> name=Sneek
> name:frl=Snits
>
> Mappers zijn geen computers en niemand die de fout snel opmerkt als het
> databasetechnisch mag, want key/value zijn verschillend immers. Ik denk
> dat daarom unieke keys in OSM gebruikt worden.

Dat los je op door expliet een tooltje te draaien, zoals dat nu ook
gebeurt.

> De dubbele value fuel;parking zou overigens door een renderer prima
> opgelost kunnen worden door twee symbolen naast elkaar te tekenen i.p.v.
> bovenop elkaar.

Dan ga je er vanuit dat de renderer ; als scheidingsteken implementeert.
Die aanname is niet XML, dus per definitie een uitbreiding op de
standaard, die zo nooit is bedoeld.


Stefan


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

Re: [OSM-talk-nl] fuel;parking

[Lambertus]

Ik denk dat je met unieke key/value combinaties veel problemen gaat 
krijgen. Stel je voor dat er meerdere name tags worden toegevoegd 
bijvoorbeeld om de friese en NL naam van een stad te taggen:
name=Sneek
name=Snits

Dit is natuurlijk fout getagd, het zou moeten zijn:
name=Sneek
name:frl=Snits

Mappers zijn geen computers en niemand die de fout snel opmerkt als het 
databasetechnisch mag, want key/value zijn verschillend immers. Ik denk 
dat daarom unieke keys in OSM gebruikt worden.

De dubbele value fuel;parking zou overigens door een renderer prima 
opgelost kunnen worden door twee symbolen naast elkaar te tekenen i.p.v. 
bovenop elkaar.


Stefan de Konink wrote:
> Lambertus wrote:
>> Stefan de Konink wrote:
>>> Lambertus wrote:
 Bij mijn beste weten is het in OSM altijd al mogelijk geweest om per 
 value meerdere onderdelen op te geven en deze te scheiden met een ';'. 
 Voorbeeldje, Thialf stadion in Heerenveen zou je kunnen taggen met:

 sport=skating;ice_hockey
>>> Wist je zelfs dan je van , gebruik kunt maken of - of | of * of & of $ 
>>> of + of ! of /... nu iemand anders die er het zelfde over denkt en je 
>>> kunt er mee communiceren... en dat maakt het semantiek. Dat wil je 
>>> volgensmij voorkomen.
>>>
>> Technisch heb je weer gelijk maar het gebruik van meerdere values per 
>> tag is de realiteit in OSM en het scheiden van de values mbv een ';' is 
>> daarbij de regel. De case die aangedragen is door Theun is dus niet fout.
> 
> De regel nu zou volgens mij meerdere keys zijn, echter dat implementeert 
> JOSM niet...
> 
> 
> Stefan
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


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

Re: [OSM-talk-nl] fuel;parking

[Stefan de Konink]

Theun wrote:
> Dat betekent dus geen meerdere gelijke keys, maar wel meerdere waarden 
> per key (gescheiden door ; ?).
> Ik weet niet of dat nogal dom is.

Het is heel dom, het vereist een nieuwe semantische interpretatie van 
xml attributen.

> Het is denk ik ook niet handig is om 
> meerdere nodes aan te maken op precies dezelfde plak omdat je meerdere 
> eigenschappen (values) voor eenzelfde key van toepassing zijn.

Dat is het ook niet, daarom moeten Key-Value pairs unique zijn per node, 
maar moeten er dus wel meerdere dezelfde keys op 1 node gezet kunnen worden.

> Blijft dat dan noch steeds dat in renderers keuzes gemaakt moeten worden 
> hoe dit te laten zien. Wat blijkbaar tot nu toe niet gebeurt.

Inderdaad, dan gaan mensen weer zeuren over volgorde ;)


Stefan

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

Re: [OSM-talk-nl] fuel;parking

[Theun]

Dat betekent dus geen meerdere gelijke keys, maar wel meerdere waarden per
key (gescheiden door ; ?).
Ik weet niet of dat nogal dom is. Het is denk ik ook niet handig is om
meerdere nodes aan te maken op precies dezelfde plak omdat je meerdere
eigenschappen (values) voor eenzelfde key van toepassing zijn. Zie het
voorbeeld van Lambertus met de sporten. Zo zijn er voor meerdere keys heel
wat situaties te bedenken om meerdere waarden te gebruiken om de
werkelijkheid te beschrijven.

Blijft dat dan noch steeds dat in renderers keuzes gemaakt moeten worden hoe
dit te laten zien. Wat blijkbaar tot nu toe niet gebeurt.


2009/2/22 Stefan de Konink 

> Theun wrote:
> > Zoals Stefan al aangeeft had ik het idee (vanuit eerdere draadjes op de
> > maillijst) dat in principe meerdere identieke tags per node aangemaakt
> > kunnen worden (wat JOSM niet ondersteunt) ipv een tag met een
> > gecombineerde value (wat JOSM wel ondersteunt qua aanmaak alleen niet
> > het laten zien van het icoon).
> > Kortom wat is goed, of is beide goed. Als je de specificatie van de API
> > of de database-struktuur bekijkt past beide hier wel in.
>
> Ik heb op dev@ voorgesteld een unique te maken op key-value; daar willen
> ze niet aan en gaan bij 0.6 alleen voor een unique op key; wat nogal dom
> is.
>
>
> Stefan
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
>
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] fuel;parking

[Stefan de Konink]

Theun wrote:
> Zoals Stefan al aangeeft had ik het idee (vanuit eerdere draadjes op de 
> maillijst) dat in principe meerdere identieke tags per node aangemaakt 
> kunnen worden (wat JOSM niet ondersteunt) ipv een tag met een 
> gecombineerde value (wat JOSM wel ondersteunt qua aanmaak alleen niet 
> het laten zien van het icoon).
> Kortom wat is goed, of is beide goed. Als je de specificatie van de API 
> of de database-struktuur bekijkt past beide hier wel in.

Ik heb op dev@ voorgesteld een unique te maken op key-value; daar willen 
ze niet aan en gaan bij 0.6 alleen voor een unique op key; wat nogal dom is.


Stefan

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

Re: [OSM-talk-nl] fuel;parking

[Theun]

Zoals ik al in mijn mail melde, met Mapnik/OSMRenderer wordt dit niet
gerenderd. Hoe moet de renderer ook bepalen welk icoon prioriteit heeft.
Ik heb nog de Opencyclemap gecontroleert, ook geen Fuel/parking icoon
(basiskaart van openfietskaart werkt nu even niet bij mij).
Mijn vraag was ook een beetje, waar vindt ik wat hier is afgesproken. Het
blijft allemaal wel heel erg vrijblijvend, waar moet een renderer vanuit
gaan?

Zoals Stefan al aangeeft had ik het idee (vanuit eerdere draadjes op de
maillijst) dat in principe meerdere identieke tags per node aangemaakt
kunnen worden (wat JOSM niet ondersteunt) ipv een tag met een gecombineerde
value (wat JOSM wel ondersteunt qua aanmaak alleen niet het laten zien van
het icoon).
Kortom wat is goed, of is beide goed. Als je de specificatie van de API of
de database-struktuur bekijkt past beide hier wel in.

In dit specifieke geval bij de tankstations langs de snelweg, had ik het
idee dat de fuel-tag hier meer op z'n plaats is.

Theun,
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] fuel;parking

[Stefan de Konink]

Lambertus wrote:
> Stefan de Konink wrote:
>> Lambertus wrote:
>>> Bij mijn beste weten is het in OSM altijd al mogelijk geweest om per 
>>> value meerdere onderdelen op te geven en deze te scheiden met een ';'. 
>>> Voorbeeldje, Thialf stadion in Heerenveen zou je kunnen taggen met:
>>>
>>> sport=skating;ice_hockey
>> Wist je zelfs dan je van , gebruik kunt maken of - of | of * of & of $ 
>> of + of ! of /... nu iemand anders die er het zelfde over denkt en je 
>> kunt er mee communiceren... en dat maakt het semantiek. Dat wil je 
>> volgensmij voorkomen.
>>
> Technisch heb je weer gelijk maar het gebruik van meerdere values per 
> tag is de realiteit in OSM en het scheiden van de values mbv een ';' is 
> daarbij de regel. De case die aangedragen is door Theun is dus niet fout.

De regel nu zou volgens mij meerdere keys zijn, echter dat implementeert 
JOSM niet...


Stefan

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

Re: [OSM-talk-nl] fuel;parking

[Lambertus]

Stefan de Konink wrote:
> Lambertus wrote:
>> Bij mijn beste weten is het in OSM altijd al mogelijk geweest om per 
>> value meerdere onderdelen op te geven en deze te scheiden met een ';'. 
>> Voorbeeldje, Thialf stadion in Heerenveen zou je kunnen taggen met:
>>
>> sport=skating;ice_hockey
> 
> Wist je zelfs dan je van , gebruik kunt maken of - of | of * of & of $ 
> of + of ! of /... nu iemand anders die er het zelfde over denkt en je 
> kunt er mee communiceren... en dat maakt het semantiek. Dat wil je 
> volgensmij voorkomen.
> 
Technisch heb je weer gelijk maar het gebruik van meerdere values per 
tag is de realiteit in OSM en het scheiden van de values mbv een ';' is 
daarbij de regel. De case die aangedragen is door Theun is dus niet fout.

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

Re: [OSM-talk-nl] fuel;parking

[Stefan de Konink]

Lambertus wrote:
> Bij mijn beste weten is het in OSM altijd al mogelijk geweest om per 
> value meerdere onderdelen op te geven en deze te scheiden met een ';'. 
> Voorbeeldje, Thialf stadion in Heerenveen zou je kunnen taggen met:
> 
> sport=skating;ice_hockey

Wist je zelfs dan je van , gebruik kunt maken of - of | of * of & of $ 
of + of ! of /... nu iemand anders die er het zelfde over denkt en je 
kunt er mee communiceren... en dat maakt het semantiek. Dat wil je 
volgensmij voorkomen.




Stefan

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

Re: [OSM-talk-nl] fuel;parking

[Lambertus]

Bij mijn beste weten is het in OSM altijd al mogelijk geweest om per 
value meerdere onderdelen op te geven en deze te scheiden met een ';'. 
Voorbeeldje, Thialf stadion in Heerenveen zou je kunnen taggen met:

sport=skating;ice_hockey

Niet dat het uitmaakt, maar dat JOSM het niet goed laat zien, soit. Doen 
de andere renderers het wel?

Zie ook de FAQ:


Stefan de Konink wrote:
> Theun wrote:
>> Vorige week een ritje gemaakt met de auto en getankt langs de snelweg. 
>> Na de data te vergelijken met de gpx-track viel mij op dat er geen 
>> "Fuel" symbool in JOSM zichtbaar was bij het tankstation (en ook niet in 
>> Mapnik/OSMrenderer). Dit wordt veroorzaakt doordat de nodes die bij de 
>> AND-node als tag amenitiy=fuel hadden er een tweede hebben bijgekregen. 
>> Nu amenity = fuel;parking. Ik kon niet echt op de OSMWiki uitvinden of 
>> dit nu de bedoeling was (twee waarden voor één key). Nu heb ik het idee 
>> dat voor de node's waar het over gaat alleen de value 'fuel' zou 
>> volstaan, er zijn altijd wel enkele parkeerplekken bij het verkooppunt 
>> (en je kunt natuurlijk even naast de pomp parkeren), maar het 
>> parkeerterrein ligt iets verderop.
>> Moeten we hier de data aanpassen, of is de data zo goed en moeten de 
>> renderers maar aangepast worden, met een bepaalde prioriteit om iconen 
>> te laten zien.
> 
> Ik weet niet of je typo onbewust was of niet ;) Maar je laatste punt is 
> een semantiek vraag. Ik zou er niet voor zijn om fuel en parking op 1 
> node te zetten. Omdat er dan ook een parser moet zijn die iets doet met 
> ';'. Wat mij betreft halen we de NL nodes op die dat hebben, en splitsen 
> ze in twee nodes.
> 
> 
> Stefan
> 
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl


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

Re: [OSM-talk-nl] fuel;parking

[Stefan de Konink]

Theun wrote:
> Vorige week een ritje gemaakt met de auto en getankt langs de snelweg. 
> Na de data te vergelijken met de gpx-track viel mij op dat er geen 
> "Fuel" symbool in JOSM zichtbaar was bij het tankstation (en ook niet in 
> Mapnik/OSMrenderer). Dit wordt veroorzaakt doordat de nodes die bij de 
> AND-node als tag amenitiy=fuel hadden er een tweede hebben bijgekregen. 
> Nu amenity = fuel;parking. Ik kon niet echt op de OSMWiki uitvinden of 
> dit nu de bedoeling was (twee waarden voor één key). Nu heb ik het idee 
> dat voor de node's waar het over gaat alleen de value 'fuel' zou 
> volstaan, er zijn altijd wel enkele parkeerplekken bij het verkooppunt 
> (en je kunt natuurlijk even naast de pomp parkeren), maar het 
> parkeerterrein ligt iets verderop.
> Moeten we hier de data aanpassen, of is de data zo goed en moeten de 
> renderers maar aangepast worden, met een bepaalde prioriteit om iconen 
> te laten zien.

Ik weet niet of je typo onbewust was of niet ;) Maar je laatste punt is 
een semantiek vraag. Ik zou er niet voor zijn om fuel en parking op 1 
node te zetten. Omdat er dan ook een parser moet zijn die iets doet met 
';'. Wat mij betreft halen we de NL nodes op die dat hebben, en splitsen 
ze in twee nodes.


Stefan

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

[OSM-talk-nl] fuel;parking

[Theun]

Vorige week een ritje gemaakt met de auto en getankt langs de snelweg. Na de
data te vergelijken met de gpx-track viel mij op dat er geen "Fuel" symbool
in JOSM zichtbaar was bij het tankstation (en ook niet in
Mapnik/OSMrenderer). Dit wordt veroorzaakt doordat de nodes die bij de
AND-node als tag amenitiy=fuel hadden er een tweede hebben bijgekregen. Nu
amenity = fuel;parking. Ik kon niet echt op de OSMWiki uitvinden of dit nu
de bedoeling was (twee waarden voor één key). Nu heb ik het idee dat voor de
node's waar het over gaat alleen de value 'fuel' zou volstaan, er zijn
altijd wel enkele parkeerplekken bij het verkooppunt (en je kunt natuurlijk
even naast de pomp parkeren), maar het parkeerterrein ligt iets verderop.
Moeten we hier de data aanpassen, of is de data zo goed en moeten de
renderers maar aangepast worden, met een bepaalde prioriteit om iconen te
laten zien.

Theun,
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl