Karel,
Queries worden trager schrijf je. Zonder analyse van de server waarop
de queries uitgevoerd worden kan ik niet zeggen dat dit de schuld is
van de grote database.
Misschien zijn er meer queries, of meer complexe queries. Ik zie ook
niet goed hoe het toevoegen van een object X (bv. een klein
grasperkje) invloed kan hebben op het opvragen een onafhankelijk
object Y (bv. vliegvelden).
Details nemen plaats in.
Details hoeven niet gerenderd te worden (hoewel amenity=parking_space
wel getoond wordt), dus de invloed van details is enerzijds op de
centrale DB, anderzijds misschiebn op de grootte van de tiles.
Aangezien die details enkel op zoomlevel 19 of zo getoond worden,
worden enkel die tiles wat groter.
Dus niet echt een probleem volgens mij. Voor de centrale databank wil
men naar de "nutteloze" nodes zonder tag kijken om iets aan de
grootte/performantie te doen. Die nodes zouden deel moeten uitmaken
van de weg en niet op zichzelf staan (zegt ment). Ik heb jammer genoeg
de voordracht op SOTM in dat verband nog niet bekeken.
Andere databanken (denk Nominatim) kunnen die "nutteloze" dingen er
van in het begin uitfilteren.
Verder zijn er hoe langer hoe meer grote bedrijven (denk Apple &
Facebook) die OSM gebruiken en waarschijnlijk we een deel van de
sponsering voor zich gaan nemen.
Als je wil vergelijken met Wikipedia, kijk dan ook eens naar Wikimedia
Commons, hoe groot moet die databank wel niet zijn met al die beelden
en video's. Volgens mij nemen die "iets" meer plaats in beslag dan een
node met wat tags.
We kunnen ook veel plaats beparen door (tongue in cheek)
- fietspaden/sidewalk als tags op weg,
- weglaten van busroutes (gebruik de app van de Lijn), fiets en wandel
routes (gebruik de wandelknooppunt app of iets dergelijks)
- luchthavens vervangen door nodes, welke weggebruiker moet er nu
weten waar de landingsbaan is
- huizen & addressen vervangen door 1 node, of zelfs adres nodes te
vervangen door interpollatie lijnen
- alle landuse weg te laten (wie moet er nu naar een weide navigeren)
- grenzen (die leiden toch maar tot discussies)
- alles ivm met nutsvoorzieningen. (*)
enz.
Voor alles wat iemand belangrijk vindt en wil inbrengen kan je wel
argumenteren dat het nutteloos is, of beter in een andere DB staat, of
compacter kan gemapped worden.
(*) maar kijk eens hoe relatief populair de voorgestelde tagging
schemas voor pipeline markers, streetcabinets e.d. waren.
mvg
m
On Sun, Nov 3, 2019 at 8:03 PM Karel Adams <fa348...@skynet.be> wrote:
>
> Marc,
>
> (parenthese over mijn conflict met DWG: ik besef dat ik niet altijd even
> correct heb gehandeld. En ik had er ook niet zo uitvoerig over moeten
> vertellen, alhier, inderdaad. Blijft de frustratie dat er op een
> verzoenend bericht mijnerzijds niet werd ingegaan, er kwam zelfs geen
> "neen", er kwam gewoon niks... Blijft mijn waarschuwing: "let wat gij
> doet, de DWG kan hard en niet altijd even konsekwent ingrijpen."
> Communicatie vooraf is erg belangrijk voor die lieden, en daar kan
> inderdaad niemand tegen zijn)
>
> Maar wat betreft "Ieder mapt wat hij/zij wil", daar heb ik twee
> bedenkingen bij:
>
> 1) we moeten de database niet nodeloos belasten. Er komt alsmaar
> informatie bij, de database groeit stevig, queries worden alsmaar
> trager. De capaciteit van de servers is niet onbeperkt, en er blijven
> ook geen sponsors gevonden worden om disken en memory bij te kopen. Ik
> ben beroepshalve bezig met serverinfrastructuur en het is een permanente
> ergernis dat er moet hardware worden toegevoegd (en dus geld worden
> uitgegeven) zonder dat het echt nodig is.
>
> 2) ik vergelijk OSM graag met wikipedia - ook dat is een project dat
> bouwt op open inbreng, nog opener dan OSM want men kan er zelfs
> bijdragen zonder een account aan te maken. Er verschijnt daar dan ook
> heel wat junk, en er is een gedefinieerde procedure om dat op te kuisen
> ("Article for Deletion"). Aan een dergelijke aanpak ontbreekt het bij
> OSM, en ik mis eraan. De huidige wollige aanpak kan nmbm niet blijven
> duren. Al dient het gezegd dat Wikipedia een encyclopedie maakt, en dus
> bewust en systematisch de lat hoog legt; en tegelijk veel zichtbaarder
> is, en dus veel meer blootgesteld aan vandalisme, waardoor er veel meer
> nood is aan procedures en strikte regels.
>
> Dank voor de openhartige en beleefde discussie!
>
> Karel
>
> On 11/2/19 9:45 PM, Marc Gemis wrote:
> > Ik sluit me volledig aan bij Jakka. Ieder mapt wat hij/zij wil.
> >
> > Het aantal parkeerplaatsen kan interessante info zijn, net zoals de
> > exacte ligging (misschien voor slechtzienden die over het terrein
> > moeten navigeren). Kleine bloemperken e.d. geven aan hoe groen een
> > stad is.
> >
> > Zo zijn er misschien ook mensen die zich afvragen wat het nut is van
> > afzonderlijke fietspaden of landingsbanen op een vliegveld of om het
> > even welk topic dat jij wel belangrijk vindt.
> >
> > Je hoort dit soort commentaren wel meer (en ik heb waarschijnlijk zelf
> > ook al wel die fout gemaakt, maar ik probeer ze niet terug te maken)
> > "ik vind dat X niet gemapped moet worden". OSM is een project met vele
> > gezichten en veel verschillend gebruik. Daar moet je mee leren leven.
> >
> > Afhankelijk van wat Karel opkuisen noemt (verwijderen?), kan ik me
> > voorstellen de DWG hem op de vingers tikt. Mappen op een plek die je
> > niet kent brengt altijd gevaren met zich mee. Dit lijkt me een typisch
> > verhaal van wie zijn * verbrand, moet op de blaren zitten. Het is een
> > beetje raar dat hij eerst over opkuisen van bloemperken spreekt en dan
> > over technisch verkeerd.
> >
> > mvg
> > & happy mapping van om het even wat je belangrijk vindt, (bij voorkeur
> > wel lokaal na survey ;-) )
> >
> > On Sat, Nov 2, 2019 at 4:55 PM Jakka <vdmfrank...@gmail.com> wrote:
> >> Op 2/11/2019 om 14:37 schreef Denis Verheyden:
> >>> Dag allen,
> >>>
> >>> Na een tijdje inactiviteit ben ik opnieuw wat verbeteringen op OSM aan
> >>> het aanbrengen (kleine stukjes GRB-import, aanvullen of verbeteren
> >>> huidige situaties).
> >>> Echter kwam ik onlangs een geval tegen dat mijns inziens overdreven
> >>> gedetailleerde mapping is:
> >>>
> >>> https://www.openstreetmap.org/#map=19/50.99435/4.47499
> >>>
> >>> <https://www.openstreetmap.org/#map=19/50.99435/4.47499>
> >>>
> >>> OpenStreetMap <https://www.openstreetmap.org/#map=19/50.99435/4.47499>
> >>> OpenStreetMap is a map of the world, created by people like you and free
> >>> to use under an open license. Hosting is supported by UCL, Bytemark
> >>> Hosting, and other partners.. Learn More Start Mapping
> >>> www.openstreetmap.org
> >>>
> >>> Ik heb het hier vooral over de individuele parkeerplaatsen bij die
> >>> winkels, ingetekend door Jakka (hopelijk dezelfde als die van de mailing
> >>> list hier ?).
> >>> Ik bedoel: dit is gewoon kaartvervuiling, zet daar gewoon 1 area met
> >>> amenity=parking en de kous is af.
> >>>
> >>> Plaatsen voor gehandicapten/PRM zou ik nog wel toelaten afzonderlijk in
> >>> te tekenen, ook al omdat het anders moeilijk in een area te definiëren
> >>> is waar men dan een tag "capacity:disabled" op zet. Dan weet je wel
> >>> hoevéél er zijn, maar je weet niet wáár ze zich bevinden.
> >>>
> >>> Een zelfde opmerking aan de fetishisten die graag afzonderlijke bomen
> >>> intekenen: stop er aub mee. Tenzij het echt een karakteristiek kenmerk
> >>> is of een echte bomenrij staat ("Allee unter den Linden" in Berlijn om
> >>> maar te zeggen), maar laat het anders gewoon zo. Er zijn betere zaken te
> >>> mappen.
> >>>
> >>> Groeten,
> >>>
> >>> Denis
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Talk-be mailing list
> >>> Talk-be@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-be
> >>>
> >> Denis,
> >>
> >> Wat betreft het detail micro mapping, niemand verplicht jou om zelfde te
> >> doen, voor parking_space mag dit volgens de wiki
> >> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space.
> >> Maar als jij dat niet graag ziet kan ik er niet aandoen.
> >> Misschien een overdreven voorbeeld van jou boom ... geen volledige
> >> kenmerken, dan kan je dat voor alles en nog wat door trekken naar
> >> gebouwen.... zet jij er steeds het aantal verdiepen erbij ? het soort
> >> dak dat erop staat ? voor wegen welke correcte surface, als er voetpaden
> >> zijn, boordstenen enz...
> >>
> >> En zoals iemand al reageerde met opkuis van gemapte zaken betreft als
> >> deze er werkelijk aanwezig zijn dan mag dit beschouwd worden als
> >> vandalisme en daar zijn regels voor.
> >>
> >> We gaan daar geen inkt meer aan verspillen iedereen zijn ding en osm
> >> wordt er beter door.
> >>
> >> Happy mapping
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
