[talk-ph] Waterways in NCR and surrounding provinces
Dear everyone, We are currently updating all waterways over NCR and parts of Rizal, Cavite, Laguna, Bulacan, Pampanga and Bataan for an internal research. We are nearly complete with the first pass of tracing and will start the review in the coming days. In some cases, we had to switch the way direction to follow the the convention [0] that the direction of the way should be downstream. Some of the waterways were also used as a relation for administrative boundaries. My question is, do admin boundary relations requires that the each member should have a consistent way direction like waterways? For your advice. [0] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver#How_to_map -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Waterways in NCR and surrounding provinces
On Thursday, 12 September, 2013 09:31 AM, maning sambale wrote: In some cases, we had to switch the way direction to follow the the convention [0] that the direction of the way should be downstream Hah, I'd never really thought of this before. I guess a lot of times I start tracing from the sea backwards inland, so I've probably got this wrong a few times. It started me thinking though. If you were able to get the elevation data for the start point and end point of a waterway, you could probably work out the direction of flow from that, and apply it automagically. So what about canals? :-) Jim ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Waterways in NCR and surrounding provinces
Good idea Jim. However it got me thinking also... in the case of Pasig river, the flow of the water depends on the time and tide of the day. Sometimes water flows inward from the bay to Laguna lake but there are times also that the water flows from the lake to the ocean (which is what seems to be natural to me, all water flows toward the ocean). Just a thought. This is the same case also in Malabon and some parts of Bulacan also :) On Sep 12, 2013 9:42 AM, Jim Morgan j...@datalude.com wrote: On Thursday, 12 September, 2013 09:31 AM, maning sambale wrote: In some cases, we had to switch the way direction to follow the the convention [0] that the direction of the way should be downstream Hah, I'd never really thought of this before. I guess a lot of times I start tracing from the sea backwards inland, so I've probably got this wrong a few times. It started me thinking though. If you were able to get the elevation data for the start point and end point of a waterway, you could probably work out the direction of flow from that, and apply it automagically. So what about canals? :-) Jim __**_ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.**org/listinfo/talk-phhttps://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Waterways in NCR and surrounding provinces
exactly my thoughts too it's called tidal estuary many boundaries in metro manila defined by rivers and (vanishing) esteros --- I explore, therefore I blog! http://www.backpackingphilippines.com http://www.facebook.com/backpackingPhilippines http://www.twitter.com/backpackPH On Sep 12, 2013, at 10:22 AM, rem zamora pompy...@gmail.com wrote: Good idea Jim. However it got me thinking also... in the case of Pasig river, the flow of the water depends on the time and tide of the day. Sometimes water flows inward from the bay to Laguna lake but there are times also that the water flows from the lake to the ocean (which is what seems to be natural to me, all water flows toward the ocean). Just a thought. This is the same case also in Malabon and some parts of Bulacan also :) On Sep 12, 2013 9:42 AM, Jim Morgan j...@datalude.com wrote: On Thursday, 12 September, 2013 09:31 AM, maning sambale wrote: In some cases, we had to switch the way direction to follow the the convention [0] that the direction of the way should be downstream Hah, I'd never really thought of this before. I guess a lot of times I start tracing from the sea backwards inland, so I've probably got this wrong a few times. It started me thinking though. If you were able to get the elevation data for the start point and end point of a waterway, you could probably work out the direction of flow from that, and apply it automagically. So what about canals? :-) Jim ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
Ik treed je analyse volledig bij. Dat is ook grotendeels de reden waarom mijn enthousiasme over OSM steeds verder weg zinkt. IMHO moet er meer projectmatig worden gewerkt aan de kaart, maar ik vrees dat dit onmogelijk is. Op 11 september 2013 00:14 schreef filip wolters filip_wolt...@hotmail.com : Ik ben blij voor jullie dat je deze situatie hebt kunnen rechtzetten. Toch blijf ik erbij dat als je een hogere kwaliteit van kaart wil hebben, met een grotere groep van vrijwilligers werkt aan een steeds gedetailleerdere kaart, het anders moet. Er moet mijn inziens een systeem zijn dat het onmogelijk maakt dat iemand random verschillende jaren gegevens van anderen zomaar kan verwijderen. Er moet getracht worden dat elke wijziging aan osm een wijziging ten goede is. Hoe is het mogelijk dat dit verschillende jaren is blijven duren, hoeveel is er verwijderd? Ligt het aan deze persoon? Grotendeels niet in mijn ogen, de werkmethode is verkeerd. Maar we hebben deze discussie in het verleden al gehad en er geen oplossing voor gevonden. T.t.z. het blijft zoals het is. Groeten, Filip ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppunt verplaatst
Tom, Als je de aanpassing hebt gemaakt, mag je me laten weten waar. Ik heb een script van Jo om de fietsknooppuntennetwerken na te kijken en aangezien Jo op andere projecten zit, zal ik dit graag om die manier nakijken. Gr, D. 2013/9/11 Marc Gemis marc.ge...@gmail.com Tom, het hangt er wat vanaf welke editor je gebruikt. iD, Potlatch, JOSM? Met deze laatste is het niet zo heel moeilijk om de relatie aan te passen. Maar omdat de beschrijving waarschijnlijk moeilijker is dat het eigenlijke werk, wacht ik even tot je laat weten met welke editor je werkt groeten m 2013/9/11 Tom Lauwereins t...@lauwereins.eu Hallo Ik ben al enige tijd actief op OSM en beperk mij tot correcties aanbrengen en hier en daar toevoegen. In Breisem bij Boutersem lijkt er een fietsknooppunt verplaatst. http://www.openstreetmap.org/browse/node/304053808 Bijgevolg moet er wat aangepast worden aan de relaties. Ik weet echter niet goed wat de best manier is om relaties aan te passen, stukken toe te voegen en andere aan te passen. Wie kan mij helpen. -- Groetjes Tom Lauwereins (aka Tom Pouce) +32 495 584448 ___ 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] Actieve gebruiker reageert niet op berichten/vragen
Het project begint bij het individu. Ik heb mijn projecten de voorbije weken voorgesteld. Verschillende anderen hebben hetzelfde gedaan. Jammer genoeg heb ik geen stemmen gehoord van mensen die willen meewerken aan die projecten. Dat is de tweede stap, blijkbaar ontbrekende stap. UrBis is een mooi voorbeeld van project matige aanpak in Belgie die wel werkt. Ik hoop dat we met AGIV/Crab dezelfde weg kunnen opgaan. Dat we dan Vlaanderen in stukken kunnen kappen en ieder een stuk van dat project kan doen en dat lost een deel van jouw probleem (adressen en huisnummers) op. Als dat toch niet doorgaat, plan ik weer een aantal gebieden te bezoeken in mijn buurt om systematisch huisnummers te verzamelen en straatnamen te controleren. Dus als je vind dat er niet genoeg huisnummers zijn: Kap het gebied in je buurt in stukken, doe elke avond een wandeling van een uurtje. Op die manier kan je een behoorlijk gebied zelf afdekken. Of wacht op meer info van AGIV/CRAB. Maar dat zal dan via JOSM gaan. En vertel ons over je project, je problemen, je oplossingen. Probeer ons warm te maken om eraan mee te doen. Ik zie nog wel geen eenvoudige werkwijze om de geimporteerde AGIV/CRAB data te controleren in de straat. Heeft iemand ideeen om dat te gaan doen ? groeten m 2013/9/11 Ivo De Broeck ivo.debro...@gmail.com Ik treed je analyse volledig bij. Dat is ook grotendeels de reden waarom mijn enthousiasme over OSM steeds verder weg zinkt. IMHO moet er meer projectmatig worden gewerkt aan de kaart, maar ik vrees dat dit onmogelijk is. Op 11 september 2013 00:14 schreef filip wolters filip_wolt...@hotmail.com: Ik ben blij voor jullie dat je deze situatie hebt kunnen rechtzetten. Toch blijf ik erbij dat als je een hogere kwaliteit van kaart wil hebben, met een grotere groep van vrijwilligers werkt aan een steeds gedetailleerdere kaart, het anders moet. Er moet mijn inziens een systeem zijn dat het onmogelijk maakt dat iemand random verschillende jaren gegevens van anderen zomaar kan verwijderen. Er moet getracht worden dat elke wijziging aan osm een wijziging ten goede is. Hoe is het mogelijk dat dit verschillende jaren is blijven duren, hoeveel is er verwijderd? Ligt het aan deze persoon? Grotendeels niet in mijn ogen, de werkmethode is verkeerd. Maar we hebben deze discussie in het verleden al gehad en er geen oplossing voor gevonden. T.t.z. het blijft zoals het is. Groeten, Filip ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ 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] Actieve gebruiker reageert niet op berichten/vragen
Marc, Even een aanvulling: één van de andere redenen dat mijn enthousiasme daalt is vooral mijn tijdsgebrek ;-) En je legt eigenlijk de vinger op de wonde. Indien meer lokaal gewerkt kan worden en de medewerkers kunnen elkaar regelmatig ontmoeten, kunnen die mensen meer gemotiveerd worden. Ik zie dat bv de ontmoeting in Lier toch positieve resultaten heeft opgeleverd. Op 11 september 2013 09:34 schreef Marc Gemis marc.ge...@gmail.com: Het project begint bij het individu. Ik heb mijn projecten de voorbije weken voorgesteld. Verschillende anderen hebben hetzelfde gedaan. Jammer genoeg heb ik geen stemmen gehoord van mensen die willen meewerken aan die projecten. Dat is de tweede stap, blijkbaar ontbrekende stap. UrBis is een mooi voorbeeld van project matige aanpak in Belgie die wel werkt. Ik hoop dat we met AGIV/Crab dezelfde weg kunnen opgaan. Dat we dan Vlaanderen in stukken kunnen kappen en ieder een stuk van dat project kan doen en dat lost een deel van jouw probleem (adressen en huisnummers) op. Als dat toch niet doorgaat, plan ik weer een aantal gebieden te bezoeken in mijn buurt om systematisch huisnummers te verzamelen en straatnamen te controleren. Dus als je vind dat er niet genoeg huisnummers zijn: Kap het gebied in je buurt in stukken, doe elke avond een wandeling van een uurtje. Op die manier kan je een behoorlijk gebied zelf afdekken. Of wacht op meer info van AGIV/CRAB. Maar dat zal dan via JOSM gaan. En vertel ons over je project, je problemen, je oplossingen. Probeer ons warm te maken om eraan mee te doen. Ik zie nog wel geen eenvoudige werkwijze om de geimporteerde AGIV/CRAB data te controleren in de straat. Heeft iemand ideeen om dat te gaan doen ? groeten m 2013/9/11 Ivo De Broeck ivo.debro...@gmail.com Ik treed je analyse volledig bij. Dat is ook grotendeels de reden waarom mijn enthousiasme over OSM steeds verder weg zinkt. IMHO moet er meer projectmatig worden gewerkt aan de kaart, maar ik vrees dat dit onmogelijk is. Op 11 september 2013 00:14 schreef filip wolters filip_wolt...@hotmail.com: Ik ben blij voor jullie dat je deze situatie hebt kunnen rechtzetten. Toch blijf ik erbij dat als je een hogere kwaliteit van kaart wil hebben, met een grotere groep van vrijwilligers werkt aan een steeds gedetailleerdere kaart, het anders moet. Er moet mijn inziens een systeem zijn dat het onmogelijk maakt dat iemand random verschillende jaren gegevens van anderen zomaar kan verwijderen. Er moet getracht worden dat elke wijziging aan osm een wijziging ten goede is. Hoe is het mogelijk dat dit verschillende jaren is blijven duren, hoeveel is er verwijderd? Ligt het aan deze persoon? Grotendeels niet in mijn ogen, de werkmethode is verkeerd. Maar we hebben deze discussie in het verleden al gehad en er geen oplossing voor gevonden. T.t.z. het blijft zoals het is. Groeten, Filip ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ 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] osm.be
Exactly that's what i was saying in one of my previous mails: openstreetmap.fr already use drupal and we might be able to resuse some of their stuff to announce events and projects. There was also some work on integrating maps. Drupal can do any of these things, in any format/layout/style and has multilingual support built-in. Plus: I know drupal and I'm talking about getting a website up and running in the next month. Maybe we can start with this and be pragmatic about this solution and worry about what technology a bit later? Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Sep 11, 2013 at 7:24 AM, Nicolas Pettiaux nico...@pettiaux.bewrote: 2013/9/11 Marc Gemis marc.ge...@gmail.com I'll agree with Ben, that reusing what other countries are doing is the way to proceed (standing on the shoulders of giants :-) ) Please do not try to reinvent the wheel by starting from scratch +1 Why not get inspiration (= copy and reuse) from openstreetmap.fr people as we have many contacts with them and they will surely give hint and suggestions (and be here during fosdem) ? Nicolas regards m On Wed, Sep 11, 2013 at 5:44 AM, Marc Gemis marc.ge...@gmail.com wrote: I believe that there was a blog post on Coding Error that stackoverflow got most traffic via google search. Google is the dominant search engine, whether we like it or not. Anyhow, Search Engine Optimization (SEO) is something you cannot neglect as a business. But the domain name is not that relevant imho. Search for rent a room in new york and the top hit is airbnb.com . No room, rent nor NY in the name. Content, metatag, links from other sites, url of pages etc. all play a role. Google only give hints on what their algorithm uses, all the rest are guesses. I would also stick the to naming convention used in the other countries so openstreetmap.be (there are e.g. openstreetmap.nl, openstreetmap.fr, openstreetmap.de ) Also what technology are they using for their sites ? Their communities (especially the German one) are larger and they might develop reusable components, that can be used on other sites. And what is the main openstreetmap.org using (read it somewhere but forgot it) regards m On Tue, Sep 10, 2013 at 9:54 PM, Glenn Plas gl...@byte-consult.bewrote: On 2013-09-10 20:06, Ivo De Broeck wrote: Its important (for Google) to have a domain name like belgiumopenstreetmap.be ( see http://ivoweb.be/wat-heb-je-nodig/domeinnaam-kiezen ); All other related url's can be redirected to that site (like osm.be and many others) Which will make you compete with yourself as the same files get indexed for every domain for all search engines if not done properly ...I'm still wondering why you claim google find that important. Sorry for being critical , but I would rather see such claims backed up by sane arguments. Glenn ___ 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 -- Nicolas Pettiaux - +32 496 24 55 01 - http://rmll.info - http://lepacte.be EuroSciPy 2013 co-chair http://www.euroscipy.org/ ___ 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] Actieve gebruiker reageert niet op berichten/vragen
zie ook interview met Ben op SOTM 2013 http://2013.stateofthemap.org/info/videos/ (wel veel achtergrondlawaai) 2013/9/11 Ivo De Broeck ivo.debro...@gmail.com Marc, Even een aanvulling: één van de andere redenen dat mijn enthousiasme daalt is vooral mijn tijdsgebrek ;-) En je legt eigenlijk de vinger op de wonde. Indien meer lokaal gewerkt kan worden en de medewerkers kunnen elkaar regelmatig ontmoeten, kunnen die mensen meer gemotiveerd worden. Ik zie dat bv de ontmoeting in Lier toch positieve resultaten heeft opgeleverd. Op 11 september 2013 09:34 schreef Marc Gemis marc.ge...@gmail.com: Het project begint bij het individu. Ik heb mijn projecten de voorbije weken voorgesteld. Verschillende anderen hebben hetzelfde gedaan. Jammer genoeg heb ik geen stemmen gehoord van mensen die willen meewerken aan die projecten. Dat is de tweede stap, blijkbaar ontbrekende stap. UrBis is een mooi voorbeeld van project matige aanpak in Belgie die wel werkt. Ik hoop dat we met AGIV/Crab dezelfde weg kunnen opgaan. Dat we dan Vlaanderen in stukken kunnen kappen en ieder een stuk van dat project kan doen en dat lost een deel van jouw probleem (adressen en huisnummers) op. Als dat toch niet doorgaat, plan ik weer een aantal gebieden te bezoeken in mijn buurt om systematisch huisnummers te verzamelen en straatnamen te controleren. Dus als je vind dat er niet genoeg huisnummers zijn: Kap het gebied in je buurt in stukken, doe elke avond een wandeling van een uurtje. Op die manier kan je een behoorlijk gebied zelf afdekken. Of wacht op meer info van AGIV/CRAB. Maar dat zal dan via JOSM gaan. En vertel ons over je project, je problemen, je oplossingen. Probeer ons warm te maken om eraan mee te doen. Ik zie nog wel geen eenvoudige werkwijze om de geimporteerde AGIV/CRAB data te controleren in de straat. Heeft iemand ideeen om dat te gaan doen ? groeten m 2013/9/11 Ivo De Broeck ivo.debro...@gmail.com Ik treed je analyse volledig bij. Dat is ook grotendeels de reden waarom mijn enthousiasme over OSM steeds verder weg zinkt. IMHO moet er meer projectmatig worden gewerkt aan de kaart, maar ik vrees dat dit onmogelijk is. Op 11 september 2013 00:14 schreef filip wolters filip_wolt...@hotmail.com: Ik ben blij voor jullie dat je deze situatie hebt kunnen rechtzetten. Toch blijf ik erbij dat als je een hogere kwaliteit van kaart wil hebben, met een grotere groep van vrijwilligers werkt aan een steeds gedetailleerdere kaart, het anders moet. Er moet mijn inziens een systeem zijn dat het onmogelijk maakt dat iemand random verschillende jaren gegevens van anderen zomaar kan verwijderen. Er moet getracht worden dat elke wijziging aan osm een wijziging ten goede is. Hoe is het mogelijk dat dit verschillende jaren is blijven duren, hoeveel is er verwijderd? Ligt het aan deze persoon? Grotendeels niet in mijn ogen, de werkmethode is verkeerd. Maar we hebben deze discussie in het verleden al gehad en er geen oplossing voor gevonden. T.t.z. het blijft zoals het is. Groeten, Filip ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
Hey, We zijn hiermee bezig hé. Ik ga de CRAB-data doorgeven aan Frederik Rodrigo van osm-fr and zij hebben een systeem dat net dit toelaat, we kappen AGIV in stukken en we beginnen gewoon te werken. Als iemand wil meewerken: mail gewoon naar frederik en vraag hem in welk formaat de adressen moeten (CSV maar welke kolommen). Zijn email is in deze presentatie ( http://www.slideshare.net/FredericRodrigo/20130906-sotmbirminghamosmose) en zeg gewoon mijn naam en hij zal weten wat we afgesproken hebben. Je kan ook wachten tot ik hem contacteer (ik heb nog wat ander werk vandaag) en helpen om de data te converteren naar de juiste CSV. Ik denk dat pieter colp ook al wat werk gedaan heeft op github maar ik ben de url even kwijt. De website past ook in dit kader vind ik. Er moet meer interactie komen tussen al deze verschillende deelnemeners/projecten. We kunnen dit doen en we moeten dit doen. Kom ook eens naar één van de meetups of nodig zelf andere mensen uit. Op die manier komen we er wel... Met vriendelijke groeten, Best regards, Ben Abelshausen 2013/9/11 Ivo De Broeck ivo.debro...@gmail.com Marc, Even een aanvulling: één van de andere redenen dat mijn enthousiasme daalt is vooral mijn tijdsgebrek ;-) En je legt eigenlijk de vinger op de wonde. Indien meer lokaal gewerkt kan worden en de medewerkers kunnen elkaar regelmatig ontmoeten, kunnen die mensen meer gemotiveerd worden. Ik zie dat bv de ontmoeting in Lier toch positieve resultaten heeft opgeleverd. Op 11 september 2013 09:34 schreef Marc Gemis marc.ge...@gmail.com: Het project begint bij het individu. Ik heb mijn projecten de voorbije weken voorgesteld. Verschillende anderen hebben hetzelfde gedaan. Jammer genoeg heb ik geen stemmen gehoord van mensen die willen meewerken aan die projecten. Dat is de tweede stap, blijkbaar ontbrekende stap. UrBis is een mooi voorbeeld van project matige aanpak in Belgie die wel werkt. Ik hoop dat we met AGIV/Crab dezelfde weg kunnen opgaan. Dat we dan Vlaanderen in stukken kunnen kappen en ieder een stuk van dat project kan doen en dat lost een deel van jouw probleem (adressen en huisnummers) op. Als dat toch niet doorgaat, plan ik weer een aantal gebieden te bezoeken in mijn buurt om systematisch huisnummers te verzamelen en straatnamen te controleren. Dus als je vind dat er niet genoeg huisnummers zijn: Kap het gebied in je buurt in stukken, doe elke avond een wandeling van een uurtje. Op die manier kan je een behoorlijk gebied zelf afdekken. Of wacht op meer info van AGIV/CRAB. Maar dat zal dan via JOSM gaan. En vertel ons over je project, je problemen, je oplossingen. Probeer ons warm te maken om eraan mee te doen. Ik zie nog wel geen eenvoudige werkwijze om de geimporteerde AGIV/CRAB data te controleren in de straat. Heeft iemand ideeen om dat te gaan doen ? groeten m 2013/9/11 Ivo De Broeck ivo.debro...@gmail.com Ik treed je analyse volledig bij. Dat is ook grotendeels de reden waarom mijn enthousiasme over OSM steeds verder weg zinkt. IMHO moet er meer projectmatig worden gewerkt aan de kaart, maar ik vrees dat dit onmogelijk is. Op 11 september 2013 00:14 schreef filip wolters filip_wolt...@hotmail.com: Ik ben blij voor jullie dat je deze situatie hebt kunnen rechtzetten. Toch blijf ik erbij dat als je een hogere kwaliteit van kaart wil hebben, met een grotere groep van vrijwilligers werkt aan een steeds gedetailleerdere kaart, het anders moet. Er moet mijn inziens een systeem zijn dat het onmogelijk maakt dat iemand random verschillende jaren gegevens van anderen zomaar kan verwijderen. Er moet getracht worden dat elke wijziging aan osm een wijziging ten goede is. Hoe is het mogelijk dat dit verschillende jaren is blijven duren, hoeveel is er verwijderd? Ligt het aan deze persoon? Grotendeels niet in mijn ogen, de werkmethode is verkeerd. Maar we hebben deze discussie in het verleden al gehad en er geen oplossing voor gevonden. T.t.z. het blijft zoals het is. Groeten, Filip ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
Hey, I use now Joomla to develop my websites. For me, Drupal is for professional developpers and big websites, Joomla is more easy. SPIP could be also a good solution ! With the package of www.icdisoft.com, there is a free Web Buider. I propose this option to my customers. Free, easy to use but limited, but only for static contents. Bye. __Teddy__ 2013/9/10 Nicolas Pettiaux nico...@pettiaux.be Dear Mr Huys, According to DNS.be, you own osm.be that does not seem to be used. The members of the belgian OpenStreetMap (http://osm.org) community are wondering if you would agree to transfer it to us to use it as a local edition of OSM, much like http://openstreetmap.fr. Much thanks in advance for your attention. Best regards, Nicolas Pettiaux -- Nicolas Pettiaux - +32 496 24 55 01 - http://rmll.info - http://lepacte.be EuroSciPy 2013 co-chair http://www.euroscipy.org/ ___ 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] osm.be
Comments inline: On 2013-09-11 05:44, Marc Gemis wrote: I believe that there was a blog post on Coding Error that stackoverflow got most traffic via google search. Google is the dominant search engine, whether we like it or not. Anyhow, Search Engine Optimization (SEO) is something you cannot neglect as a business. But the domain name is not that relevant imho. I'm pretty much on top of that subject professionally, try to follow me on this: when you have the same pages on different domains, your domains will compete with eachother as they are exactly the same, if you don't redirect correctly. Hence why I mention to do this the right way as I see it too many times that people buy every domain they can think of. Next to that google will crawl every domain seperately as it has no idea it's the same, so your traffic will grow exponentially. On a static site, that is usually not an issue, but once you go drupal/wordpress/joomla/etc... your server will get hits. I've had this happen to huge customers (agenda.nieuwsblad.be for example). The servers that do this where dying just because crawlers had a free pass, everyone came by, Russian, Chinese , Google , Bing, fake google bots, bots not respecting your robots.txt, etc etc ... this accounted for more than 60% of the traffic, those numbers went into the terrabytes monthly. So by just limiting and holding google's hand instead of buying new servers as the customer planned, this platform is now doing almost nothing and analytics do not suffer. Here is a site explaining this in more detail: http://www.k2seo.com/competing-with-yourself/ Search for rent a room in new york and the top hit is airbnb.com http://airbnb.com . No room, rent nor NY in the name. Content, metatag, links from other sites, url of pages etc. all play a role. Google only give hints on what their algorithm uses, all the rest are guesses. I fail to see the point of the statement in this context. My point was sending a warning to pay attention to multiple sites serving the exact same content (alias domains). I would also stick the to naming convention used in the other countries so openstreetmap.be http://openstreetmap.be (there are e.g. openstreetmap.nl http://openstreetmap.nl, openstreetmap.fr http://openstreetmap.fr, openstreetmap.de http://openstreetmap.de ) Also what technology are they using for their sites ? Their communities (especially the German one) are larger and they might develop reusable components, that can be used on other sites. And what is the main openstreetmap.org http://openstreetmap.org using (read it somewhere but forgot it) openstreetmaps.org uses Ruby on Rails, the code is available here : https://github.com/openstreetmap/openstreetmap-website Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
Wat betreft het AGIV/CRAB verhaal kan ik misschien mee helpen. Bij mijn ex-werkgever was het CRAB project aan mij toegewezen en als gevolg heb ik daar ook heel wat expertise over en enkele contacten bij AGIV. Nu weet ik het niet als jullie weten dat het CRAB-decreet van de Vlaamse regering bepaald dat het CRAB sinds 1 juni 2011 de enige authentieke geografische bron is voor adressen in Vlaanderen. Iedere Vlaamse gemeente heeft sinds die datum uiterlijk 4 jaar de tijd gekregen om de CRAB databank voor hun grondgebied te controleren en te laten valideren door AGIV. Van zodra een gemeente gevalideerd is, is die gemeente als enige verantwoordelijk voor de adressen op hun grondgebied, de actualisatie van de adressen en bijgevolg ook voor straatnamen. Tot aan de validatie is het mogelijk dat AGIV nog adressen inlaad vanuit andere bronnen zoals daar zijn het kadaster en de kruispuntbank. Vanaf 1 juni 2015 zou het CRAB dus volledig correct horen te zijn. Echter gemeenten kennende zou het mij niet verbazen dat ze nog uitstel gaan krijgen. Wat betreft de adresposities in het CRAB, één adres kan meerdere posities hebben in het CRAB. Oorspronkelijk was het de bedoeling dat posities van adressen afgeleid werden van ruimtelijke objecten (in het CRAB aangeduid als terreinobject) zoals kadastrale percelen, administratieve percelen (ADP in het GRB), gebouwen (GBG in het GRB),... Echter werd deze werkwijze bij de meeste gemeenten niet aanvaard omdat zij simpel een punt wilden prikken op de kaart. Daarom hebben ze bij AGIV besloten om toch een entiteit adresposities in het leven te roepen. Deze adresposities krijgen ook een aard mee zoals bijvoorbeeld: manuele aanduiding van de brievenbus, manuele aanduiding van het gebouw, manuele aanduiding van toegang tot het perceel, afgeleid van kadastraal perceel, afgeleid van grb gebouw, interpolatie ahv nevenliggende adressen,... In het totaal zijn er ongeveer een 20-tal. Nu is het wel zo dat de interpolaties in het eindresultaat allemaal verdwenen horen te zijn. Echter met mijn vorige paragraaf over de adresposities in gedachten kan het natuurlijk niet de bedoeling zijn om al deze adresposities in OSM te krijgen dat zou voor een immense verwarring zorgen. Nu is het ook zo dat iedere gemeente zelf kan bepalen welke adresposities ze aanmaakt in het CRAB, de ene gemeente zal misschien uitsluitend voor de manuele aanduiding van brievenbus gaan terwijl een andere gemeente het enkel bij de manuele aanduiding van het gebouw zal houden terwijl nog andere gemeenten verschillende adresposities zullen bijhouden. Dit heeft dan als gevolg dat wij niet kunnen zeggen om het bij één soort van aanduiding te houden omdat er dan zonder twijfel adressen zullen ontbreken. Bij mijn ex-werkgever had ik een hiërarchie voorzien van de soorten adresposities en voor ieder adres op grondgebied van een gemeente ging ik dan kijken welke adresposities beschikbaar waren in de online databank van AGIV om dan die bovenaan in de hiërarchie in onze lokale databank bij de gemeente te bewaren. Om nu terug te komen op het zoeken van een manier om de geïmporteerde data van het CRAB te controleren. Dat is eigenlijk niet aan de orde omdat net de gemeenten daar 4 jaar (sinds 1 juni 2011) de tijd voor gekregen hebben en dat dus hun taak is. Waarom het werk van een ambtenaar controleren als zij er net voor betaald worden door ons burgers. MAAR nu ik dat hier zo zit te schrijven bedenk ik net dat AGIV ook een meldingensysteem voorzien heeft waar andere instanties fouten die ze ontdekt hebben in het CRAB mee kunnen melden aan de gemeenten. In dat oogpunt zou die controle dan weer wel goed kunnen zijn om zo vanuit OSM ook meldingen te kunnen doen als we fouten tegenkomen. Zo deze epistel is even mijn two cents voor wat het CRAB betreft en heeft eigenlijk nog weinig vandoen met de onderwerpregel :-P Misschien nog dit het is uiteindelijk de bedoeling dat het kadaster en het rijksregister het CRAB ook moeten gaan gebruiken als hun bron voor adressen in Vlaanderen. Hier waren enkele jaren geleden al politieke afspraken over. Voorlopig doen het kadaster en het rijksregister nog hun eigen ding en worden deze als bronnen voor het CRAB gebruikt maar op termijn zou die gegevensstroom zich dus moeten omkeren. Groeten, Ben Op 11/09/2013 9:34, Marc Gemis schreef: Het project begint bij het individu. Ik heb mijn projecten de voorbije weken voorgesteld. Verschillende anderen hebben hetzelfde gedaan. Jammer genoeg heb ik geen stemmen gehoord van mensen die willen meewerken aan die projecten. Dat is de tweede stap, blijkbaar ontbrekende stap. UrBis is een mooi voorbeeld van project matige aanpak in Belgie die wel werkt. Ik hoop dat we met AGIV/Crab dezelfde weg kunnen opgaan. Dat we dan Vlaanderen in stukken kunnen kappen en ieder een stuk van dat project kan doen en dat lost een deel van jouw probleem (adressen en huisnummers) op. Als dat toch niet doorgaat, plan
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
Wow, merci @ Ben! :-) Ik heb ook al een tijdje geleden ondertussen met CRAB gewerkt maar ken niet zoveel details! Heb zelf eigenlijk wel wat fouten ontdekt. Maar dat terzijde. Is er misschien een overzicht van gemeentes die alles up-to-date hebben? Kwestie van misschien met de die te beginnen? Het manueel controleren is toch iets dat we gaan moeten doen hoe onoverkomelijk het ook lijkt. Er is soms bestaande data waar adressen best op toegevoegd worden. Met vriendelijke groeten, Best regards, Ben Abelshausen 2013/9/11 Ben Schalley thras...@screenshaker.com Wat betreft het AGIV/CRAB verhaal kan ik misschien mee helpen. Bij mijn ex-werkgever was het CRAB project aan mij toegewezen en als gevolg heb ik daar ook heel wat expertise over en enkele contacten bij AGIV. Nu weet ik het niet als jullie weten dat het CRAB-decreet van de Vlaamse regering bepaald dat het CRAB sinds 1 juni 2011 de enige authentieke geografische bron is voor adressen in Vlaanderen. Iedere Vlaamse gemeente heeft sinds die datum uiterlijk 4 jaar de tijd gekregen om de CRAB databank voor hun grondgebied te controleren en te laten valideren door AGIV. Van zodra een gemeente gevalideerd is, is die gemeente als enige verantwoordelijk voor de adressen op hun grondgebied, de actualisatie van de adressen en bijgevolg ook voor straatnamen. Tot aan de validatie is het mogelijk dat AGIV nog adressen inlaad vanuit andere bronnen zoals daar zijn het kadaster en de kruispuntbank. Vanaf 1 juni 2015 zou het CRAB dus volledig correct horen te zijn. Echter gemeenten kennende zou het mij niet verbazen dat ze nog uitstel gaan krijgen. Wat betreft de adresposities in het CRAB, één adres kan meerdere posities hebben in het CRAB. Oorspronkelijk was het de bedoeling dat posities van adressen afgeleid werden van ruimtelijke objecten (in het CRAB aangeduid als terreinobject) zoals kadastrale percelen, administratieve percelen (ADP in het GRB), gebouwen (GBG in het GRB),... Echter werd deze werkwijze bij de meeste gemeenten niet aanvaard omdat zij simpel een punt wilden prikken op de kaart. Daarom hebben ze bij AGIV besloten om toch een entiteit adresposities in het leven te roepen. Deze adresposities krijgen ook een aard mee zoals bijvoorbeeld: manuele aanduiding van de brievenbus, manuele aanduiding van het gebouw, manuele aanduiding van toegang tot het perceel, afgeleid van kadastraal perceel, afgeleid van grb gebouw, interpolatie ahv nevenliggende adressen,... In het totaal zijn er ongeveer een 20-tal. Nu is het wel zo dat de interpolaties in het eindresultaat allemaal verdwenen horen te zijn. Echter met mijn vorige paragraaf over de adresposities in gedachten kan het natuurlijk niet de bedoeling zijn om al deze adresposities in OSM te krijgen dat zou voor een immense verwarring zorgen. Nu is het ook zo dat iedere gemeente zelf kan bepalen welke adresposities ze aanmaakt in het CRAB, de ene gemeente zal misschien uitsluitend voor de manuele aanduiding van brievenbus gaan terwijl een andere gemeente het enkel bij de manuele aanduiding van het gebouw zal houden terwijl nog andere gemeenten verschillende adresposities zullen bijhouden. Dit heeft dan als gevolg dat wij niet kunnen zeggen om het bij één soort van aanduiding te houden omdat er dan zonder twijfel adressen zullen ontbreken. Bij mijn ex-werkgever had ik een hiërarchie voorzien van de soorten adresposities en voor ieder adres op grondgebied van een gemeente ging ik dan kijken welke adresposities beschikbaar waren in de online databank van AGIV om dan die bovenaan in de hiërarchie in onze lokale databank bij de gemeente te bewaren. Om nu terug te komen op het zoeken van een manier om de geïmporteerde data van het CRAB te controleren. Dat is eigenlijk niet aan de orde omdat net de gemeenten daar 4 jaar (sinds 1 juni 2011) de tijd voor gekregen hebben en dat dus hun taak is. Waarom het werk van een ambtenaar controleren als zij er net voor betaald worden door ons burgers. MAAR nu ik dat hier zo zit te schrijven bedenk ik net dat AGIV ook een meldingensysteem voorzien heeft waar andere instanties fouten die ze ontdekt hebben in het CRAB mee kunnen melden aan de gemeenten. In dat oogpunt zou die controle dan weer wel goed kunnen zijn om zo vanuit OSM ook meldingen te kunnen doen als we fouten tegenkomen. Zo deze epistel is even mijn two cents voor wat het CRAB betreft en heeft eigenlijk nog weinig vandoen met de onderwerpregel :-P Misschien nog dit het is uiteindelijk de bedoeling dat het kadaster en het rijksregister het CRAB ook moeten gaan gebruiken als hun bron voor adressen in Vlaanderen. Hier waren enkele jaren geleden al politieke afspraken over. Voorlopig doen het kadaster en het rijksregister nog hun eigen ding en worden deze als bronnen voor het CRAB gebruikt maar op termijn zou die gegevensstroom zich dus moeten omkeren. Groeten, Ben Op 11/09/2013 9:34, Marc Gemis schreef: Het project begint bij het individu. Ik
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
In Brussel zijn we dus ook alle adressen aan het toevoegen, maar wat ons betreft is die data dan nog niet compleet, ook al kunnen we er daar de gebouwcontouren aan toevoegen. Het wordt pas echt interessant als je ook weet welke POI op dat adres/die locatie aanwezig zijn en daarvoor kan je toch best ter plaatse een bezoekje brengen. Mijn manier van werken zal dus waarschijnlijk worden om die AGIV-adresdata als extra informatiebron te gaan gebruiken, naast de luchtfoto's, eigen foto's en surveyresultaten. Ik denk niet dat 'k eraan ga beginnen om ze in bulk toe te voegen, behalve als een straat nagenoeg compleet is, misschien. Jo Op 11 september 2013 11:09 schreef Ben Abelshausen ben.abelshau...@gmail.com: Wow, merci @ Ben! :-) Ik heb ook al een tijdje geleden ondertussen met CRAB gewerkt maar ken niet zoveel details! Heb zelf eigenlijk wel wat fouten ontdekt. Maar dat terzijde. Is er misschien een overzicht van gemeentes die alles up-to-date hebben? Kwestie van misschien met de die te beginnen? Het manueel controleren is toch iets dat we gaan moeten doen hoe onoverkomelijk het ook lijkt. Er is soms bestaande data waar adressen best op toegevoegd worden. Met vriendelijke groeten, Best regards, Ben Abelshausen 2013/9/11 Ben Schalley thras...@screenshaker.com Wat betreft het AGIV/CRAB verhaal kan ik misschien mee helpen. Bij mijn ex-werkgever was het CRAB project aan mij toegewezen en als gevolg heb ik daar ook heel wat expertise over en enkele contacten bij AGIV. Nu weet ik het niet als jullie weten dat het CRAB-decreet van de Vlaamse regering bepaald dat het CRAB sinds 1 juni 2011 de enige authentieke geografische bron is voor adressen in Vlaanderen. Iedere Vlaamse gemeente heeft sinds die datum uiterlijk 4 jaar de tijd gekregen om de CRAB databank voor hun grondgebied te controleren en te laten valideren door AGIV. Van zodra een gemeente gevalideerd is, is die gemeente als enige verantwoordelijk voor de adressen op hun grondgebied, de actualisatie van de adressen en bijgevolg ook voor straatnamen. Tot aan de validatie is het mogelijk dat AGIV nog adressen inlaad vanuit andere bronnen zoals daar zijn het kadaster en de kruispuntbank. Vanaf 1 juni 2015 zou het CRAB dus volledig correct horen te zijn. Echter gemeenten kennende zou het mij niet verbazen dat ze nog uitstel gaan krijgen. Wat betreft de adresposities in het CRAB, één adres kan meerdere posities hebben in het CRAB. Oorspronkelijk was het de bedoeling dat posities van adressen afgeleid werden van ruimtelijke objecten (in het CRAB aangeduid als terreinobject) zoals kadastrale percelen, administratieve percelen (ADP in het GRB), gebouwen (GBG in het GRB),... Echter werd deze werkwijze bij de meeste gemeenten niet aanvaard omdat zij simpel een punt wilden prikken op de kaart. Daarom hebben ze bij AGIV besloten om toch een entiteit adresposities in het leven te roepen. Deze adresposities krijgen ook een aard mee zoals bijvoorbeeld: manuele aanduiding van de brievenbus, manuele aanduiding van het gebouw, manuele aanduiding van toegang tot het perceel, afgeleid van kadastraal perceel, afgeleid van grb gebouw, interpolatie ahv nevenliggende adressen,... In het totaal zijn er ongeveer een 20-tal. Nu is het wel zo dat de interpolaties in het eindresultaat allemaal verdwenen horen te zijn. Echter met mijn vorige paragraaf over de adresposities in gedachten kan het natuurlijk niet de bedoeling zijn om al deze adresposities in OSM te krijgen dat zou voor een immense verwarring zorgen. Nu is het ook zo dat iedere gemeente zelf kan bepalen welke adresposities ze aanmaakt in het CRAB, de ene gemeente zal misschien uitsluitend voor de manuele aanduiding van brievenbus gaan terwijl een andere gemeente het enkel bij de manuele aanduiding van het gebouw zal houden terwijl nog andere gemeenten verschillende adresposities zullen bijhouden. Dit heeft dan als gevolg dat wij niet kunnen zeggen om het bij één soort van aanduiding te houden omdat er dan zonder twijfel adressen zullen ontbreken. Bij mijn ex-werkgever had ik een hiërarchie voorzien van de soorten adresposities en voor ieder adres op grondgebied van een gemeente ging ik dan kijken welke adresposities beschikbaar waren in de online databank van AGIV om dan die bovenaan in de hiërarchie in onze lokale databank bij de gemeente te bewaren. Om nu terug te komen op het zoeken van een manier om de geïmporteerde data van het CRAB te controleren. Dat is eigenlijk niet aan de orde omdat net de gemeenten daar 4 jaar (sinds 1 juni 2011) de tijd voor gekregen hebben en dat dus hun taak is. Waarom het werk van een ambtenaar controleren als zij er net voor betaald worden door ons burgers. MAAR nu ik dat hier zo zit te schrijven bedenk ik net dat AGIV ook een meldingensysteem voorzien heeft waar andere instanties fouten die ze ontdekt hebben in het CRAB mee kunnen melden aan de gemeenten. In dat oogpunt zou die controle dan weer wel goed kunnen
Re: [OSM-talk-be] osm.be
Good idea! I would be prepared to join in Brussels or Leuven if that's more convenient! I can join thursday next week... Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Sep 11, 2013 at 11:13 AM, Nicolas Pettiaux nico...@pettiaux.bewrote: 2013/9/11 Jo winfi...@gmail.com The underlying technology is of less importance for the people who will add content later on. Those interfaces are very similar. true The decision what it will be, should depend on who is going to set up the server (and on technical possibilities, of course). +1 My vote goes to: use what openstreetmap.fr are using. +1 Plus: I know drupal and I'm talking about getting a website up and running in the next month. Maybe we can start with this and be pragmatic about this solution and worry about what technology a bit later? yes. Thanks Ben. I propose a meeting to get some people together and discuss the case for 2 hours before going to eat together. Leuven (where Jo is), Gent (where Ben is) or Brussels (where Emerzh, BenoitL, Pierre P and myself are) would be convenient locations for me. What about a Thursday at 18 or 19 in the coming weeks ? Best regards, Nicolas -- Nicolas Pettiaux - +32 496 24 55 01 - http://rmll.info - http://lepacte.be EuroSciPy 2013 co-chair http://www.euroscipy.org/ ___ 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] Actieve gebruiker reageert niet op berichten/vragen
On 2013-09-11 11:16, Jo wrote: In Brussel zijn we dus ook alle adressen aan het toevoegen, maar wat ons betreft is die data dan nog niet compleet, ook al kunnen we er daar de gebouwcontouren aan toevoegen. Het wordt pas echt interessant als je ook weet welke POI op dat adres/die locatie aanwezig zijn en daarvoor kan je toch best ter plaatse een bezoekje brengen. Mijn manier van werken zal dus waarschijnlijk worden om die AGIV-adresdata als extra informatiebron te gaan gebruiken, naast de luchtfoto's, eigen foto's en surveyresultaten. Ik denk niet dat 'k eraan ga beginnen om ze in bulk toe te voegen, behalve als een straat nagenoeg compleet is, misschien. I have to aggree , I've pondered over automatic imports a lot by compairing OSM to AGIV and there are so many differences (buildings in particular) that I came to the conclusion that we should do this manually, by humans. In my village alone (a few 1000 houses - tops) It took me so much time compairing different datasets. I believe AGIV has more accurate buildings, but data in OSM from field work is also valuable that you just cannot destroy those by blindly importing another source. Maybe we could set up a system like the Cameroon thing, where you assign yourself a grid to work in. I cannot find the url back immediately but that system sure works and I believe the source of the webpage that manages the grids is available on github too. Ben, can you help me on this link? Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
De reeds gevalideerde gemeenten zijn terug te vinden op http://www.agiv.be/gis/projecten/?artid=1541 Toevoegen van adressen aan bestaande data... ok dat is juist! Maar bijvoorbeeld in the field gaan kijken als (ieder) adres wel bestaat is dan weer overdreven. Echter als er bij controles en bvb steekproeven toch fouten zouden gevonden worden in de CRAB gegevens zou hier idealiter een CRAB melding van gemaakt moeten worden en nu komt een maar... ik heb net gelezen dat momenteel enkel deelnemers aan GDI Vlaanderen meldingen kunnen maken via LARA (de eigen adresbeheer toepassing van AGIV.) Groeten, Ben Op 11/09/2013 11:09, Ben Abelshausen schreef: Wow, merci @ Ben! :-) Ik heb ook al een tijdje geleden ondertussen met CRAB gewerkt maar ken niet zoveel details! Heb zelf eigenlijk wel wat fouten ontdekt. Maar dat terzijde. Is er misschien een overzicht van gemeentes die alles up-to-date hebben? Kwestie van misschien met de die te beginnen? Het manueel controleren is toch iets dat we gaan moeten doen hoe onoverkomelijk het ook lijkt. Er is soms bestaande data waar adressen best op toegevoegd worden. Met vriendelijke groeten, Best regards, Ben Abelshausen 2013/9/11 Ben Schalley thras...@screenshaker.com mailto:thras...@screenshaker.com Wat betreft het AGIV/CRAB verhaal kan ik misschien mee helpen. Bij mijn ex-werkgever was het CRAB project aan mij toegewezen en als gevolg heb ik daar ook heel wat expertise over en enkele contacten bij AGIV. Nu weet ik het niet als jullie weten dat het CRAB-decreet van de Vlaamse regering bepaald dat het CRAB sinds 1 juni 2011 de enige authentieke geografische bron is voor adressen in Vlaanderen. Iedere Vlaamse gemeente heeft sinds die datum uiterlijk 4 jaar de tijd gekregen om de CRAB databank voor hun grondgebied te controleren en te laten valideren door AGIV. Van zodra een gemeente gevalideerd is, is die gemeente als enige verantwoordelijk voor de adressen op hun grondgebied, de actualisatie van de adressen en bijgevolg ook voor straatnamen. Tot aan de validatie is het mogelijk dat AGIV nog adressen inlaad vanuit andere bronnen zoals daar zijn het kadaster en de kruispuntbank. Vanaf 1 juni 2015 zou het CRAB dus volledig correct horen te zijn. Echter gemeenten kennende zou het mij niet verbazen dat ze nog uitstel gaan krijgen. Wat betreft de adresposities in het CRAB, één adres kan meerdere posities hebben in het CRAB. Oorspronkelijk was het de bedoeling dat posities van adressen afgeleid werden van ruimtelijke objecten (in het CRAB aangeduid als terreinobject) zoals kadastrale percelen, administratieve percelen (ADP in het GRB), gebouwen (GBG in het GRB),... Echter werd deze werkwijze bij de meeste gemeenten niet aanvaard omdat zij simpel een punt wilden prikken op de kaart. Daarom hebben ze bij AGIV besloten om toch een entiteit adresposities in het leven te roepen. Deze adresposities krijgen ook een aard mee zoals bijvoorbeeld: manuele aanduiding van de brievenbus, manuele aanduiding van het gebouw, manuele aanduiding van toegang tot het perceel, afgeleid van kadastraal perceel, afgeleid van grb gebouw, interpolatie ahv nevenliggende adressen,... In het totaal zijn er ongeveer een 20-tal. Nu is het wel zo dat de interpolaties in het eindresultaat allemaal verdwenen horen te zijn. Echter met mijn vorige paragraaf over de adresposities in gedachten kan het natuurlijk niet de bedoeling zijn om al deze adresposities in OSM te krijgen dat zou voor een immense verwarring zorgen. Nu is het ook zo dat iedere gemeente zelf kan bepalen welke adresposities ze aanmaakt in het CRAB, de ene gemeente zal misschien uitsluitend voor de manuele aanduiding van brievenbus gaan terwijl een andere gemeente het enkel bij de manuele aanduiding van het gebouw zal houden terwijl nog andere gemeenten verschillende adresposities zullen bijhouden. Dit heeft dan als gevolg dat wij niet kunnen zeggen om het bij één soort van aanduiding te houden omdat er dan zonder twijfel adressen zullen ontbreken. Bij mijn ex-werkgever had ik een hiërarchie voorzien van de soorten adresposities en voor ieder adres op grondgebied van een gemeente ging ik dan kijken welke adresposities beschikbaar waren in de online databank van AGIV om dan die bovenaan in de hiërarchie in onze lokale databank bij de gemeente te bewaren. Om nu terug te komen op het zoeken van een manier om de geïmporteerde data van het CRAB te controleren. Dat is eigenlijk niet aan de orde omdat net de gemeenten daar 4 jaar (sinds 1 juni 2011) de tijd voor gekregen hebben en dat dus hun taak is. Waarom het werk van een ambtenaar controleren als zij er net voor betaald worden door ons burgers. MAAR nu ik dat hier zo zit te schrijven bedenk ik net dat AGIV ook een meldingensysteem voorzien heeft
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
Do you mean the osm tasking manager? http://tasks.hotosm.org I already helped create a small fix to allow JOSM to load extra data per square and merge it with OSM-data. Something we did for the central african republic. I was thinking of repeating this for AGIV but the french already have something like this for addresses. (at least that's what they told me at state of the map) Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Sep 11, 2013 at 11:27 AM, Glenn Plas gl...@byte-consult.be wrote: On 2013-09-11 11:16, Jo wrote: In Brussel zijn we dus ook alle adressen aan het toevoegen, maar wat ons betreft is die data dan nog niet compleet, ook al kunnen we er daar de gebouwcontouren aan toevoegen. Het wordt pas echt interessant als je ook weet welke POI op dat adres/die locatie aanwezig zijn en daarvoor kan je toch best ter plaatse een bezoekje brengen. Mijn manier van werken zal dus waarschijnlijk worden om die AGIV-adresdata als extra informatiebron te gaan gebruiken, naast de luchtfoto's, eigen foto's en surveyresultaten. Ik denk niet dat 'k eraan ga beginnen om ze in bulk toe te voegen, behalve als een straat nagenoeg compleet is, misschien. I have to aggree , I've pondered over automatic imports a lot by compairing OSM to AGIV and there are so many differences (buildings in particular) that I came to the conclusion that we should do this manually, by humans. In my village alone (a few 1000 houses - tops) It took me so much time compairing different datasets. I believe AGIV has more accurate buildings, but data in OSM from field work is also valuable that you just cannot destroy those by blindly importing another source. Maybe we could set up a system like the Cameroon thing, where you assign yourself a grid to work in. I cannot find the url back immediately but that system sure works and I believe the source of the webpage that manages the grids is available on github too. Ben, can you help me on this link? 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] Actieve gebruiker reageert niet op berichten/vragen
On 2013-09-11 13:25, Ben Abelshausen wrote: Do you mean the osm tasking manager? http://tasks.hotosm.org I already helped create a small fix to allow JOSM to load extra data per square and merge it with OSM-data. Something we did for the central african republic. I was thinking of repeating this for AGIV but the french already have something like this for addresses. (at least that's what they told me at state of the map) Met vriendelijke groeten, Best regards, Ben Abelshausen Yup, that is the one... I like that approach, loosely coupled so not many constraints. It would help dividing the country (like it needs more division) and manage the spread of the work. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On 2013-09-11 07:24, Nicolas Pettiaux wrote : Why not get inspiration (= copy and reuse) from openstreetmap.fr http://openstreetmap.fr people as we have many contacts with them and they will surely give hint and suggestions (and be here during fosdem) ? I see now what you mean with a site. I thought that you wanted to write urgent pages like containing the specifications for traffic zones and speed limits because there is none and we don't know how to map them. Regarding this kind of non showy content, pure HTML is simpler than wiki code and much more sharable (a simple HTML page can be put in an email, not openstreetmap.fr, you need not use the same program to share content). Cheers, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On Wed, Sep 11, 2013 at 4:24 PM, André Pirard a.pirard.pa...@gmail.comwrote: I thought that you wanted to write urgent pages like containing the specifications for traffic zones and speed limits because there is none and we don't know how to map them. this is implemented in the BENELUX-preset for Belgium. You can always reverse engineer them to write the documentation :-) m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On 2013-09-11 05:44, Marc Gemis wrote : Search for rent a room in new york and the top hit is airbnb.com http://airbnb.com . No room, rent nor NY in the name. Content, metatag, links from other sites, url of pages etc. all play a role. Google only give hints on what their algorithm uses, all the rest are guesses. I always skip the first few Google hits because they are most often ads for sites that pay to be first. Those are worse answers to a query than the following ones. According to what I saw, Google even passes the query content to some remotely related but high pay sites which build up pages supposed to exactly match your request. When you're in the site, you repeat the same search and you find nothing. But while searching, they tried to change your mind about your interest. No, the domain name is nothing more that another word at best. Speaking of guesses, I guess that the best attractor is simply invisible text. Cheers, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On 2013-09-11 17:53, Ivo De Broeck wrote : Hmm I only can say, that I have build a small website about "Kinderyoga Re-born in Duffel". When I ask google "Kinderyoga Duffel", this are the results: - first payed advertises (gray) then Gouden gids then the site Re-born But you don't have to follow the rules of google ;-). Google profiles you and, in the first hits, you receive pages supposed to meet your interests. It's possible to become Google anonymous (to change your Google ID) but it's so long to explain and to do and it lasts so shortly before they relate the new ID to the former one that it has now become in vain. Eavesdropping is illegal but every single move Google does is towards that. Their captcha system (1)? Just a way to know you have visited the site. And consumer defense seems to be blind. When I was at work, I devised a translation table between ISO8859-1 (latin-1) (on the network) and the Macintosh character set (in Mac OS). I wanted Apple to participate but they alleged the San Francisco earthquake not to do it. It was a Macintosh "resource" file containing my name. It was first used in Steve Dorner's Eudora (e-mail) and, via each and every Macintosh Internet software, it made its way towards Netscape 3 (yes, my name in it, you may sit down ;-)). Good old days. One day, I happened to make some simple query like "Pirard Macintosh" and I was surprised to find a Mac developer page regarding character sets and advertising my translation resource. Then I had the stupid idea to repeat the same query after replacing Macintosh or Apple with Microsoft and, oops, popped up ... a porn page !!! That's one of the reasons why I'm using Ubuntu/Debian/Linux ;-) Google dared not profile people by those days. They started in the News partially, then more and more, and as nobody complained they did it in Google search too, and on and on. Wonder why the Web query is sent to Google first when you click a search result and look at that query and see if you understand the information that leaves your system. Cheers, André. (1) Google's captcha shows two words: the captcha itself and another word using us as Optical Recognition machines. I recommend not decoding the second word but translating it to French. If we do all the same joke, they will end up with a funny OCR result. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On 2013-09-11 17:53, Ivo De Broeck wrote: Hmm I only can say, that I have build a small website about Kinderyoga Re-born in Duffel. When I ask google Kinderyoga Duffel, this are the results: - first payed advertises (gray) then Gouden gids then the site Re-born your results don't need to match mine, and that is because you are living in a search bubble (we probably all do), unless you anonymise your browser, you WILL be a victim of this technique. That is the reason when you tell someone verbally : The 3rd result in google is the link I mean and that persons says: That's a different link here and then everyone is confused. So keep this in mind when trying to get points across, SEO is one side of the search services. The other side is user profiling, data mining and highly focused marketing. In your example the 'in' word is also ignored btw. If you want to get out of the bubble: http://dontbubble.us/ Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On Wed, Sep 11, 2013 at 5:53 PM, Ivo De Broeck ivo.debro...@gmail.comwrote: Kinderyoga Duffel dat is al behoorlijk specifiek. Het zou knapper zijn moest je ook bovenaan staan met gewoon Kinderyoga. De enige betrouwbare bron op het gebied van SEO voor google is Matt Cutts. De reden: hij leidt een van de teams bij google. Als je hem als bron vermeldt wil ik het geloven :) Back to English: Whenever we want to to SEO for the openstreetmap Belgium site, we have to think for which search queries we want to attract people. When they search for OpenStreetMap Belgie/Belgique/Belgien/Belgium, it will be more or less normal to arrive at our site. But when one wants to attract new mappers, they might be looking for something totally different. (e.g. a free map for a garmin device, as I did 2.5 years ago). But as Matt Cutts once said: focus on good content first ! I assume the first version will look a lot like the French one. Which specific content do we want to start with ? Who will be the editors ? Translators ? regards m groeten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
Hmm I only can say, that I have build a small website about Kinderyoga Re-born in Duffel. When I ask google Kinderyoga Duffel, this are the results: - first payed advertises (gray) then Gouden gids then the site Re-born But you don't have to follow the rules of google ;-). 2013/9/11 André Pirard a.pirard.pa...@gmail.com On 2013-09-11 05:44, Marc Gemis wrote : Search for rent a room in new york and the top hit is airbnb.com . No room, rent nor NY in the name. Content, metatag, links from other sites, url of pages etc. all play a role. Google only give hints on what their algorithm uses, all the rest are guesses. I always skip the first few Google hits because they are most often ads for sites that pay to be first. Those are worse answers to a query than the following ones. According to what I saw, Google even passes the query content to some remotely related but high pay sites which build up pages supposed to exactly match your request. When you're in the site, you repeat the same search and you find nothing. But while searching, they tried to change your mind about your interest. No, the domain name is nothing more that another word at best. Speaking of guesses, I guess that the best attractor is simply invisible text. Cheers, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Ivo De Broeck Valleilaan 13 3360 Korbeek-lo tel +32 16 43 84 93 gsm +32 486 17 61 13 spanje tel +34 966 841 726 gsm +34 603 661 778 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppunt verplaatst
Ik gebruik meestal Potlatch maar af en toe ook JOSM. In Potlatch leek het niet zo eenvoudig, misschien moet ik eens in JOSM proberen. Grtjs Tom Op 11 september 2013 05:30 schreef Marc Gemis marc.ge...@gmail.com: Tom, het hangt er wat vanaf welke editor je gebruikt. iD, Potlatch, JOSM? Met deze laatste is het niet zo heel moeilijk om de relatie aan te passen. Maar omdat de beschrijving waarschijnlijk moeilijker is dat het eigenlijke werk, wacht ik even tot je laat weten met welke editor je werkt groeten m 2013/9/11 Tom Lauwereins t...@lauwereins.eu Hallo Ik ben al enige tijd actief op OSM en beperk mij tot correcties aanbrengen en hier en daar toevoegen. In Breisem bij Boutersem lijkt er een fietsknooppunt verplaatst. http://www.openstreetmap.org/browse/node/304053808 Bijgevolg moet er wat aangepast worden aan de relaties. Ik weet echter niet goed wat de best manier is om relaties aan te passen, stukken toe te voegen en andere aan te passen. Wie kan mij helpen. -- Groetjes Tom Lauwereins (aka Tom Pouce) +32 495 584448 ___ 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 -- Groetjes Tom Lauwereins (aka Tom Pouce) +32 495 584448 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
Le 10/09/13 16:27, Glenn Plas a écrit : While all the suggestions are nice, I think we're mostly looking for a company to sponsor OSM (eg. giving the hosting for free). I'm willing to do that with my company, a 'powered by' is good enough for me as this gives me exposure in something I can live with. but I would like to see more details on what is going to be served so I know what machine to throw at it so I can decide. Hi guys, I am also currently founding a Company which will use OSM data. Champs Libres SCRLFS (cooperative with social purpose) will also be happy to give some space on webservers. If it is not for the website, we may sponsor osm-be later or for something else :-) Julien Glenn ___ 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] Fietsknooppunt verplaatst
Laten we al proberen te beschrijven hoe je het knooppunt zelf verzet. - selecteer het oude knooppunt. - rechts onder eigenschappen/leden zal je rcn_ref XXX en de knooppunt relatie zien - selecteer de lijn met rcn_ref en klik op de knop verwijderen eronder - selecteer de lijn met de relatie - je zou nu weer verwijderen kunnen klikken, maar omdat je verder knopen en stretaten wel toevoegen, is het beter om op bewerken te klikken - in de dialoog die nu opent zie je bovenaan de eigenschappen van de relatie, daaronder de leden. - selecteer de lijn met het te verwijderen knooppunt. (is waarschijnlijk geselecteerd). klik het onderste vuilbakje aan. - hou de dialoog open - selecteer het nieuwe knooppunt (op de kruising van de wegen plaatsen, niet ernaast !) - klik op de bovenste knop in het midden met grijs vakje bovenaan en pijltje naar link. Dit voegt de knoop bovenaan in de lijst toe. - klik op ok van de dialoog. - voeg de tag rcn_ref XXX toe aan de nieuwe knoop. In principe moet je iets gelijkaardigs doen voor de route - Voor stukjes straat die in zijn geheel weg mogen kan je hetzelfde doen als voor de knoop. - In sommige gevallen moet je wegen splitsen. Klik op de knoop waar de splitsing moet gebeuren, klik op 'p' Dit doe je best voordat je de relatie dialoog van de route opent (zeker als beginner) - Hou er rekening mee dat in de route relatie de wegen gesorteerd zitten van de lage nummer naar de hoge nummer - Dus als je wegen toevoegt aan de relatie moet je die op de juiste plaats zetten. De eenvoudige manier (om uit te leggen) Zelfde knop gebruiken als voor knoop, daarna met tweede knop links (lijst met naar ondergebogen pijl) klikken tot de straat op de juiste positie staat. Je kan ook werken met knoppen 2-3 in het midden die op andere plekken in de lijst toevoegen. Experimenteer zelf maar - Je ziet dat de volgorde juist is als er een ononderbroken lijn staat naast de wegen (links van die knoppen in het midden). Hopelijk is het een eenvoudig knooppunt dat je moet toevoegen/verwijderen, d.w.z. eentje op een eenvoudig T-kruispunt. Jo heeft ooit een naam bedacht voor de complexere, waar je 2 knopen moet gebruiken om 1 knooppunt aan te geven. (bv. als de ene splitsing op de linkeroever is en de andere op de rechteroever). Maar dat zou ons te ver leiden zo 's morgens vroeg. Succes, en vuur je vragen maar af mocht je nog met problemen zitten. groeten m 2013/9/12 Glenn Plas gl...@byte-consult.be On 2013-09-11 22:46, Tom Lauwereins wrote: Ik gebruik meestal Potlatch maar af en toe ook JOSM. In Potlatch leek het niet zo eenvoudig, misschien moet ik eens in JOSM proberen. Voor het betere editing werk, zeker met relations is JOSM een must gewoon. Ik raad u sterk aan om de misschien te veranderen in een 'zeker en vast'. Je gaat geen spijt hebben, JOSM is echt een prachtige applicatie, ik haat echt java door de miserie van in het begin, maar als iemand me vraagt: wat is uw favoriete java applicatie moet ik altijd JOSM antwoorden. Ik blijf elke week dingen in JOSM ontdekken, na al die jaren. MapCSS, de validator, plugins... ze maken het leven zo gemakkelijk. Warm aanbevolen, zoals een warme choco op een koude regendag. Veel success, er is veel expertise hier omtrent JOSM, dus bij vragen: just shoot! 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] Fietsknooppunt verplaatst
er stond een foutje in mijn vorige mail, hier volgt de correctie - in de netwerk relatie worden enkel knooppunten en routes geplaatst, GEEN individuele straten of paden - in de route relatie worden enkel straten of paden gezet, in volgorde van het laagste nummer naar het hoogste. Geen knopen in deze relatie de foutieve zin was: - je zou nu weer verwijderen kunnen klikken, maar omdat je verder knopen en stretaten wel toevoegen, is het beter om op bewerken te klikken dat moet dus - je zou nu weer verwijderen kunnen klikken, maar omdat je verder knopen en misschien routes wil toevoegen aan de relatie, is het beter om op bewerken te klikken 2013/9/12 Marc Gemis marc.ge...@gmail.com Laten we al proberen te beschrijven hoe je het knooppunt zelf verzet. - selecteer het oude knooppunt. - rechts onder eigenschappen/leden zal je rcn_ref XXX en de knooppunt relatie zien - selecteer de lijn met rcn_ref en klik op de knop verwijderen eronder - selecteer de lijn met de relatie - je zou nu weer verwijderen kunnen klikken, maar omdat je verder knopen en stretaten wel toevoegen, is het beter om op bewerken te klikken - in de dialoog die nu opent zie je bovenaan de eigenschappen van de relatie, daaronder de leden. - selecteer de lijn met het te verwijderen knooppunt. (is waarschijnlijk geselecteerd). klik het onderste vuilbakje aan. - hou de dialoog open - selecteer het nieuwe knooppunt (op de kruising van de wegen plaatsen, niet ernaast !) - klik op de bovenste knop in het midden met grijs vakje bovenaan en pijltje naar link. Dit voegt de knoop bovenaan in de lijst toe. - klik op ok van de dialoog. - voeg de tag rcn_ref XXX toe aan de nieuwe knoop. In principe moet je iets gelijkaardigs doen voor de route - Voor stukjes straat die in zijn geheel weg mogen kan je hetzelfde doen als voor de knoop. - In sommige gevallen moet je wegen splitsen. Klik op de knoop waar de splitsing moet gebeuren, klik op 'p' Dit doe je best voordat je de relatie dialoog van de route opent (zeker als beginner) - Hou er rekening mee dat in de route relatie de wegen gesorteerd zitten van de lage nummer naar de hoge nummer - Dus als je wegen toevoegt aan de relatie moet je die op de juiste plaats zetten. De eenvoudige manier (om uit te leggen) Zelfde knop gebruiken als voor knoop, daarna met tweede knop links (lijst met naar ondergebogen pijl) klikken tot de straat op de juiste positie staat. Je kan ook werken met knoppen 2-3 in het midden die op andere plekken in de lijst toevoegen. Experimenteer zelf maar - Je ziet dat de volgorde juist is als er een ononderbroken lijn staat naast de wegen (links van die knoppen in het midden). Hopelijk is het een eenvoudig knooppunt dat je moet toevoegen/verwijderen, d.w.z. eentje op een eenvoudig T-kruispunt. Jo heeft ooit een naam bedacht voor de complexere, waar je 2 knopen moet gebruiken om 1 knooppunt aan te geven. (bv. als de ene splitsing op de linkeroever is en de andere op de rechteroever). Maar dat zou ons te ver leiden zo 's morgens vroeg. Succes, en vuur je vragen maar af mocht je nog met problemen zitten. groeten m 2013/9/12 Glenn Plas gl...@byte-consult.be On 2013-09-11 22:46, Tom Lauwereins wrote: Ik gebruik meestal Potlatch maar af en toe ook JOSM. In Potlatch leek het niet zo eenvoudig, misschien moet ik eens in JOSM proberen. Voor het betere editing werk, zeker met relations is JOSM een must gewoon. Ik raad u sterk aan om de misschien te veranderen in een 'zeker en vast'. Je gaat geen spijt hebben, JOSM is echt een prachtige applicatie, ik haat echt java door de miserie van in het begin, maar als iemand me vraagt: wat is uw favoriete java applicatie moet ik altijd JOSM antwoorden. Ik blijf elke week dingen in JOSM ontdekken, na al die jaren. MapCSS, de validator, plugins... ze maken het leven zo gemakkelijk. Warm aanbevolen, zoals een warme choco op een koude regendag. Veel success, er is veel expertise hier omtrent JOSM, dus bij vragen: just shoot! 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] [josm-dev] An incredible and unexpected use of JOSM
On 2013-09-11 09:21, Florian Lohoff wrote: But i wouldnt be worried - There will be a day where OSM will be THE ONLY important map provider. Its economically not possible for Nokia and TomTom to get the same map detail level as we do. So they'll highlight the crowd nature of OSM and try to spread FUD about reliability and accuracy of OSM for the next 10 Years. This has all happened before in the Linux universe and in the end there is Linux on any embedded device and server and the Desktop, Microsoft has been dominating for 30 Years will be irrelevant by tomorrow. This is so true. We only have to wait. Once OSM will be more and more known by the public and they see that they can get maps and updates for the entire world for free and that they can get updated maps (technically) every single day instead of having to pay € 100 euro (usually much more for in-car nav) for just the map or a year's worth of updates then the consumer will demand it. Really the only thing car manufacturers need to install in a car is an Android tablet. What we can do to accelerate that process is to make the map even better. So basically: carry on. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [josm-dev] An incredible and unexpected use of JOSM
On Wed, Sep 11, 2013 at 09:55:42AM +0200, Maarten Deen wrote: What we can do to accelerate that process is to make the map even better. So basically: carry on. Be patient, Be relaxed and have fun. We'll all be in the Hall of Fame. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] FYI: 30C3 Call for Participation
Deadline for submissions: September 15, 2013 (23:59 UTC) http://events.ccc.de/2013/07/18/30c3-call-for-participation-en/ -- Michael ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Outperforming TomTom
Unfortunately not available everywhere yet, but as a step towards becoming the best map in the world: after the publication of open address data in the Netherlands two years ago, starting this month open traffic data will be available in The Netherlands http://www.ndw.nu/pagina/nl/103/datalevering/ This will mean that OSM navigation apps will be able to outperform TomTom due to the better road quality. Hopefully the rest of Europe can follow soon. This would inevitably mean headlines in major newspapers and therefore a huge increase in mappers. Let's rock! Cheers, Johan ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Talk-nl Digest, Vol 79, Issue 2
Hallo Frank, Ik ben een complete leek bij openstreetmap maar wel geïnteresseerd. N.a.v. je mail op 7 september j.l. : Talk-nl Digest, Vol 79, Issue 2 reageer ik op het Gigapan Topraster. Daaarbij heb ik even gekeken naar mij woonplaats Almere, waarbij ik zover mogelijk ben ingezoomd. Wat mij betreft is die kaart maar zeer beperkt bruikbaar, n.l. alleen geschikt om in de gewenste wijk te komen. De straten in een wijk worden wel aangegeven, echter zo onnauwkeurig, dat je er niet mee kunt navigeren, omdat busbanen, fietspaden, etc. vaak hetzelfde worden aangegeven als gewone wegen. De huidige OS-map is beter! mvg, Theo de Kraker Op 7 september 2013 14:00 schreef talk-nl-requ...@openstreetmap.org: Send Talk-nl mailing list submissions to talk-nl@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-nl or, via email, send a message with subject or body 'help' to talk-nl-requ...@openstreetmap.org You can reach the person managing the list at talk-nl-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-nl digest... Today's Topics: 1. Gebruik data Basisregistratie Topografie (Frank Steggink) -- Message: 1 Date: Fri, 06 Sep 2013 18:16:41 +0200 From: Frank Steggink stegg...@steggink.org To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Subject: [OSM-talk-nl] Gebruik data Basisregistratie Topografie Message-ID: 5229ffe9.7010...@steggink.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hoi, Bij mij en diverse anderen was de indruk aanwezig dat data van de Basisregistratie Topografie (BRT) in OSM niet toegestaan is, omdat de licentie (CC-BY-SA) incompatible zou zijn met ODbL. De licentie van alle BRT-producten (vector ?n raster) blijkt geruime tijd geleden omgezet te zijn naar CC-BY [1]. Je zou kunnen twijfelen of dit wel compatible is, maar (IANAL) waarschijnlijk is vermelding op de attribution pagina voldoende. Het Kadaster weet ook dat OSM geaggregeerd is uit allerlei bronnen, waaronder de vele duizenden mappers die veel energie hierin hebben gestoken. Misschien is dit voer voor legal-talk om dit helemaal uit te kristalliseren. Anyways, de onduidelijkheid die nog rest, wordt volledig weggevaagd door Ben Bruns. Hij heeft op diverse plekken uiting gegeven dat het wat hem betreft prima is dat BRT-data wordt hergebruikt binnen OSM of op andere plekken. Het Kadaster juicht dat juist toe. Gisteren was ik op een bijeenkomst waar hij dit nogmaals expliciet duidelijk heeft gemaakt. Als hij dat als product manager zegt, dan is dit ongetwijfeld waar. Let op, ik wil met dit bericht geen discussie opstarten over de import van BRT data in OSM, maar alleen dat hergebruik door het Kadaster, bij monde van Ben Bruns, wordt toegejuicht (mits vermelding op de attribution pagina). Gegeven de data van eerdere imports (AND, 3dShapes), zal het toevoegen hiervan een zeer grote inspanning vereisen! Dit geldt ook voor kleine gebieden! De actualiteit van TOP10NL is wel goed, aangezien het Kadaster erin geslaagd is om de productiecyclus zodanig te stroomlijnen dat de oudste bladen 2 jaar oud zijn. Dat betekent dat TOP10NL in het algemeen even oud of nieuwer is dan de Bing-foto's, die grofweg van 2010 zijn. Verder een nieuwtje: het Kadaster is ook een paar jaar bezig geweest met het automatisch generaliseren van de TOP10NL data naar een schaal van 1:5. Een belangrijke fase hierin is afgerond, namelijk dat heel Nederland is omgezet en de rasterbeelden hiervan zijn vrijgegeven voor het publiek (uiteraard ook CC-BY). De data is bij het Kadaster aan te vragen, maar staat nog niet op PDOK. Uiteraard heb ik, in goede traditie, een aanvraag ingediend en de data ontvangen ;) Voor degenen die alvast willen kijken, heb ik alle bladen aan elkaar geplakt en op Gigapan gezet: http://gigapan.com/gigapans?query=top50raster. Het Kadaster hoort graag feedback, dus fouten kunnen gemeld worden. Het is nog niet duidelijk waar, maar hopelijk zal die vraag gauw beantwoord zal worden. Groeten, Frank [1] http://www.kadaster.nl/BRT -- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl End of Talk-nl Digest, Vol 79, Issue 2 ** ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] 90.000 RAF-luchtfoto’s van Nederland online
Beste OSM'ers, Kwam dit tegen: http://www.dans.knaw.nl/content/categorieen/nieuws/9-raf-luchtfoto%E2%80%99s-van-nederland-online http://library.wur.nl/WebQuery/geoportal/raf -- International Amsterdam Bitcoin Conference 2013, wednesday 6 to friday 8 november Science Park Amsterdam http://bitcoinference.com/ Met vriendelijke groet, Best regards, Bas de Lange +31 (0)6 166 26 950 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Talk-nl Digest, Vol 79, Issue 2
Dag Theo, De 1:5 kaart is een gegeneraliseerd product. Dat betekent dat er data moet worden weggelaten om een goed kaartbeeld te geven. De kartografische weergave is belangrijk bij generalisatie, maar dat gaat (zoals je ziet) wel ten koste van de nauwkeurigheid. Dit schaalniveau is dan ook meer bedoeld voor orientatie. De reden dat ik een gigapan hiervan heb gemaakt (en niet van de 1:25000 kaart) is dat afgelopen week deze nieuwe versie is vrijgegeven. Het bijzondere hieraan is dat de generalisatie (d.w.z. aanpassingen aan de kaarten om dingen weg te laten en/of te verschuiven) geheel automatisch is verlopen. Voor een landsdekkende serie is dat een unieke presentatie. Mocht iemand toch iets met de BRT-data in OSM willen doen, dan zou ik, naast er eerst heel goed over nadenken of je het echt moet willen, de TOP10NL vectordata gebruiken. De 1:5 kaart en de nog te releasen data is hiervoor veel minder geschikt. Ik had misschien beter moeten benadrukken dat de instemming van het Kadaster voor hergebruik van de BRT-data niet specifiek voor de 1:5 kaart bedoeld is. Groeten, Frank On 11-9-2013 12:30, Theo de Kraker wrote: Hallo Frank, Ik ben een complete leek bij openstreetmap maar wel geïnteresseerd. N.a.v. je mail op 7 september j.l. : Talk-nl Digest, Vol 79, Issue 2 reageer ik op het Gigapan Topraster. Daaarbij heb ik even gekeken naar mij woonplaats Almere, waarbij ik zover mogelijk ben ingezoomd. Wat mij betreft is die kaart maar zeer beperkt bruikbaar, n.l. alleen geschikt om in de gewenste wijk te komen. De straten in een wijk worden wel aangegeven, echter zo onnauwkeurig, dat je er niet mee kunt navigeren, omdat busbanen, fietspaden, etc. vaak hetzelfde worden aangegeven als gewone wegen. De huidige OS-map is beter! mvg, Theo de Kraker Op 7 september 2013 14:00 schreef talk-nl-requ...@openstreetmap.org mailto:talk-nl-requ...@openstreetmap.org: Send Talk-nl mailing list submissions to talk-nl@openstreetmap.org mailto:talk-nl@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-nl or, via email, send a message with subject or body 'help' to talk-nl-requ...@openstreetmap.org mailto:talk-nl-requ...@openstreetmap.org You can reach the person managing the list at talk-nl-ow...@openstreetmap.org mailto:talk-nl-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-nl digest... Today's Topics: 1. Gebruik data Basisregistratie Topografie (Frank Steggink) -- Message: 1 Date: Fri, 06 Sep 2013 18:16:41 +0200 From: Frank Steggink stegg...@steggink.org mailto:stegg...@steggink.org To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org mailto:talk-nl@openstreetmap.org Subject: [OSM-talk-nl] Gebruik data Basisregistratie Topografie Message-ID: 5229ffe9.7010...@steggink.org mailto:5229ffe9.7010...@steggink.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hoi, Bij mij en diverse anderen was de indruk aanwezig dat data van de Basisregistratie Topografie (BRT) in OSM niet toegestaan is, omdat de licentie (CC-BY-SA) incompatible zou zijn met ODbL. De licentie van alle BRT-producten (vector ?n raster) blijkt geruime tijd geleden omgezet te zijn naar CC-BY [1]. Je zou kunnen twijfelen of dit wel compatible is, maar (IANAL) waarschijnlijk is vermelding op de attribution pagina voldoende. Het Kadaster weet ook dat OSM geaggregeerd is uit allerlei bronnen, waaronder de vele duizenden mappers die veel energie hierin hebben gestoken. Misschien is dit voer voor legal-talk om dit helemaal uit te kristalliseren. Anyways, de onduidelijkheid die nog rest, wordt volledig weggevaagd door Ben Bruns. Hij heeft op diverse plekken uiting gegeven dat het wat hem betreft prima is dat BRT-data wordt hergebruikt binnen OSM of op andere plekken. Het Kadaster juicht dat juist toe. Gisteren was ik op een bijeenkomst waar hij dit nogmaals expliciet duidelijk heeft gemaakt. Als hij dat als product manager zegt, dan is dit ongetwijfeld waar. Let op, ik wil met dit bericht geen discussie opstarten over de import van BRT data in OSM, maar alleen dat hergebruik door het Kadaster, bij monde van Ben Bruns, wordt toegejuicht (mits vermelding op de attribution pagina). Gegeven de data van eerdere imports (AND, 3dShapes), zal het toevoegen hiervan een zeer grote inspanning vereisen! Dit geldt ook voor kleine gebieden! De actualiteit van TOP10NL is wel goed, aangezien het Kadaster erin geslaagd is om de productiecyclus zodanig te stroomlijnen dat de oudste bladen 2 jaar oud zijn. Dat betekent dat TOP10NL in het algemeen even oud of nieuwer is dan
Re: [talk-au] Victoria - cutting the data polygon
Hi Brett (and everyone else), It looks like your first assumption is probably correct: The Victoria polygon you're using is too big, it comprises of 10147 nodes (and can be found at http://downloads.cloudmade.com/oceania/australia_and_new_zealand/australia/victoria/victoria.poly ). If you don't mind having small parts of NSW and SA in the VIC polygon, then I recommend using a super-simple custom polygon for this. JOSM has a plugin called poly that allows you to import and export to poly files, so I just made up a quick 4 node polygon of Victoria that should be fine to use: Victoria 1 140.955887 -33.713994 150.349971 -36.765387 150.312801 -39.210773 140.958166 -39.214549 140.955887 -33.713994 END END The notes on using the splitter ( http://wiki.openstreetmap.org/wiki/Splitter ) under the --polygon-file part states that, The name of a file containing a bounding polygon in osmosis polygon file format. Splitter uses this file when calculating the areas. It first calculates a grid using the given --resolution. The input file is read and for each node, a counter is increased for the related grid area. If the input file contains a bounding box, this is applied to the grid so that nodes outside of the bounding box are ignored. Next, if specified, the bounding polygon is used to zero those grid elements outside of the bounding polygon area. If the polygon area(s) describe(s) a rectilinear area with no more than 40 vertices, splitter will try to create output files that fit exactly into the area, else it will approximate the polygon area with rectangles. - Which just means that the splitter likes rectangles that fit lat / lon lines, and hence doesn't like anything with diagonal lines and lots of complexity. The --resolution parameter sounds like it enables you to specify how big it can make the split off squares when approximating diagonal parts of the polygon. The bigger the squares, the less it fits with the polygon, but it'll be much faster to compute. So it looks like a smaller --resolution number makes for bigger squares, by default it uses --resolution=13 Regardless, the Victoria.poly file I've provided here should work fine for you. I've used the poly file from http://download.geofabrik.de/australia-oceania/australia.html when creating mkgmap files for use with splitter, and also when using phyghtmap to get contours australia-wide (at 10m resolution I would expect about 1GB of contours in pbf format Australia-wide). So the Australia-wide polygon on the geofabrik.de website has 13 nodes with diagonal parts and it all works fine, so my 4 node polygon of Victoria should also work fine, hopefully without any tweaks to its geometry. Let us know if you have any further issues, and if you can, provide a link to any largish files in future rather than having them in the email body or attachment. Cheers :-) -- http://www.fastmail.fm - mmm... Fastmail... Victoria.poly Description: Binary data ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Labgeo/UFRGS
Parte do teu trabalho manual também vai ser corrigir erros de grafia nos nomes e ajustar alguns contornos manualmente. Os nomes estão todos em letras maiúsculas, tens que colocá-los com minúsculas e iniciais maiusculas. Eu teria scripts pra fazer isso, pra Linux. On Sep 11, 2013 2:59 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Labgeo, não Geolab haha. On Sep 11, 2013 2:58 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Augusto, eu já importei alguns desses dados (as categorias com menos dados). São 995 praças ao total, se quiseres importar tens que fazer uma revisão manual antes porque muitas estão com um nome numérico. Notei alguns/vários erros nos dados do GEOLAB. Assim, terás que fazer uma conflacao manual, verificando cada objeto. Posso te mandar o que sobrou para importar, já convertido para o formato OSM. Mas não esqueça de comparar cada objeto com o que já existe no OSM hoje. Vi mais de um caso (vários na verdade) em que o OSM estava mais correto que o GEOLAB. Os dados possuem uma tag CATEGORIA que especifica o que cada objeto é. Mas é um código e alguns dos códigos eu não consegui decifrar. Praças é PCA. O arquivo também tem dados que não faz sentido importar, como as linhas diretrizes. Há outros arquivos no mesmo conjunto de dados que contém informação sobre a vegetação e a hidrologia. Talvez você queira olhar esses também. Estou viajando e volto dia 8 de outubro, quando voltar posso te ajudar melhor. Se importares algo, crie um usuário só pra isso e de preferência guarde os números dos teus changesets. Abraços, Fernando On Sep 11, 2013 12:05 PM, Augusto Stoffel arstof...@yahoo.com.br wrote: Pessoal (especialmente Fernando), Então os dados do Labgeo estão legalmente OK para importação? Notei que o arquivo eixo_ruas.zip [1] no Diagnóstico Ambiental de Porto Alegre contém as praças, parques e esplandas, que eu estou disposto a importar para o OSM (a longo prazo em suaves prestações). Eu precisaria de umas breves dicas para começar esse trabalho. Primeiro, entendo que o processo de conflação seria manual. Envolveria criar uma camada no JOSM com os dados do Labgeo e copiar as praças para a camada principal, uma a uma, checando em cada caso se a coisa faz sentido mesmo. Está correto isso? O segundo problema é converter os arquivos do Labgeo para um formato suportado pelo OSM. Eu consigo abrir o arquivo eixo_ruas.shp no Quantum GIS e filtrar as praças, mas não descobri como exportar para um formato JOSM-friendly. Podes me dar umas dicas gerais sobre como fazer? Aliás, tem mais alguma coisa interessante no Labgeo sobre Porto Alegre além das ruas e praças? Eu não encontrei... De repente eles tem mais dados que não estão no site que eles poderiam nos dar (quiça o contorno das edificações), e com certeza eles ao menos responderiam nossos emails. Obrigado. Augusto. [1] http://www.ecologia.ufrgs.br/labgeo/arquivos/downloads/dados/Diagnostico_Ambiental_POA/cd/Base_cartografica/eixos_ruas.zip ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Labgeo/UFRGS
Pessoal (especialmente Fernando), Então os dados do Labgeo estão legalmente OK para importação? Notei que o arquivo eixo_ruas.zip [1] no Diagnóstico Ambiental de Porto Alegre contém as praças, parques e esplandas, que eu estou disposto a importar para o OSM (a longo prazo em suaves prestações). Eu precisaria de umas breves dicas para começar esse trabalho. Primeiro, entendo que o processo de conflação seria manual. Envolveria criar uma camada no JOSM com os dados do Labgeo e copiar as praças para a camada principal, uma a uma, checando em cada caso se a coisa faz sentido mesmo. Está correto isso? O segundo problema é converter os arquivos do Labgeo para um formato suportado pelo OSM. Eu consigo abrir o arquivo eixo_ruas.shp no Quantum GIS e filtrar as praças, mas não descobri como exportar para um formato JOSM-friendly. Podes me dar umas dicas gerais sobre como fazer? Aliás, tem mais alguma coisa interessante no Labgeo sobre Porto Alegre além das ruas e praças? Eu não encontrei... De repente eles tem mais dados que não estão no site que eles poderiam nos dar (quiça o contorno das edificações), e com certeza eles ao menos responderiam nossos emails. Obrigado. Augusto. [1] http://www.ecologia.ufrgs.br/labgeo/arquivos/downloads/dados/Diagnostico_Ambiental_POA/cd/Base_cartografica/eixos_ruas.zip ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Uma ferramenta para gerar feeds de qualidade do mapa
Pessoal, Vejam esta ferramenta que permite gerar feeds customizados por região do mapa para diversas ferramentas de qualidade do OpenStreetMap: http://tyrasd.github.io/osm-qa-feeds/ Abs, Vitor ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Labgeo/UFRGS
Augusto, eu já importei alguns desses dados (as categorias com menos dados). São 995 praças ao total, se quiseres importar tens que fazer uma revisão manual antes porque muitas estão com um nome numérico. Notei alguns/vários erros nos dados do GEOLAB. Assim, terás que fazer uma conflacao manual, verificando cada objeto. Posso te mandar o que sobrou para importar, já convertido para o formato OSM. Mas não esqueça de comparar cada objeto com o que já existe no OSM hoje. Vi mais de um caso (vários na verdade) em que o OSM estava mais correto que o GEOLAB. Os dados possuem uma tag CATEGORIA que especifica o que cada objeto é. Mas é um código e alguns dos códigos eu não consegui decifrar. Praças é PCA. O arquivo também tem dados que não faz sentido importar, como as linhas diretrizes. Há outros arquivos no mesmo conjunto de dados que contém informação sobre a vegetação e a hidrologia. Talvez você queira olhar esses também. Estou viajando e volto dia 8 de outubro, quando voltar posso te ajudar melhor. Se importares algo, crie um usuário só pra isso e de preferência guarde os números dos teus changesets. Abraços, Fernando On Sep 11, 2013 12:05 PM, Augusto Stoffel arstof...@yahoo.com.br wrote: Pessoal (especialmente Fernando), Então os dados do Labgeo estão legalmente OK para importação? Notei que o arquivo eixo_ruas.zip [1] no Diagnóstico Ambiental de Porto Alegre contém as praças, parques e esplandas, que eu estou disposto a importar para o OSM (a longo prazo em suaves prestações). Eu precisaria de umas breves dicas para começar esse trabalho. Primeiro, entendo que o processo de conflação seria manual. Envolveria criar uma camada no JOSM com os dados do Labgeo e copiar as praças para a camada principal, uma a uma, checando em cada caso se a coisa faz sentido mesmo. Está correto isso? O segundo problema é converter os arquivos do Labgeo para um formato suportado pelo OSM. Eu consigo abrir o arquivo eixo_ruas.shp no Quantum GIS e filtrar as praças, mas não descobri como exportar para um formato JOSM-friendly. Podes me dar umas dicas gerais sobre como fazer? Aliás, tem mais alguma coisa interessante no Labgeo sobre Porto Alegre além das ruas e praças? Eu não encontrei... De repente eles tem mais dados que não estão no site que eles poderiam nos dar (quiça o contorno das edificações), e com certeza eles ao menos responderiam nossos emails. Obrigado. Augusto. [1] http://www.ecologia.ufrgs.br/labgeo/arquivos/downloads/dados/Diagnostico_Ambiental_POA/cd/Base_cartografica/eixos_ruas.zip ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Labgeo/UFRGS
Labgeo, não Geolab haha. On Sep 11, 2013 2:58 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Augusto, eu já importei alguns desses dados (as categorias com menos dados). São 995 praças ao total, se quiseres importar tens que fazer uma revisão manual antes porque muitas estão com um nome numérico. Notei alguns/vários erros nos dados do GEOLAB. Assim, terás que fazer uma conflacao manual, verificando cada objeto. Posso te mandar o que sobrou para importar, já convertido para o formato OSM. Mas não esqueça de comparar cada objeto com o que já existe no OSM hoje. Vi mais de um caso (vários na verdade) em que o OSM estava mais correto que o GEOLAB. Os dados possuem uma tag CATEGORIA que especifica o que cada objeto é. Mas é um código e alguns dos códigos eu não consegui decifrar. Praças é PCA. O arquivo também tem dados que não faz sentido importar, como as linhas diretrizes. Há outros arquivos no mesmo conjunto de dados que contém informação sobre a vegetação e a hidrologia. Talvez você queira olhar esses também. Estou viajando e volto dia 8 de outubro, quando voltar posso te ajudar melhor. Se importares algo, crie um usuário só pra isso e de preferência guarde os números dos teus changesets. Abraços, Fernando On Sep 11, 2013 12:05 PM, Augusto Stoffel arstof...@yahoo.com.br wrote: Pessoal (especialmente Fernando), Então os dados do Labgeo estão legalmente OK para importação? Notei que o arquivo eixo_ruas.zip [1] no Diagnóstico Ambiental de Porto Alegre contém as praças, parques e esplandas, que eu estou disposto a importar para o OSM (a longo prazo em suaves prestações). Eu precisaria de umas breves dicas para começar esse trabalho. Primeiro, entendo que o processo de conflação seria manual. Envolveria criar uma camada no JOSM com os dados do Labgeo e copiar as praças para a camada principal, uma a uma, checando em cada caso se a coisa faz sentido mesmo. Está correto isso? O segundo problema é converter os arquivos do Labgeo para um formato suportado pelo OSM. Eu consigo abrir o arquivo eixo_ruas.shp no Quantum GIS e filtrar as praças, mas não descobri como exportar para um formato JOSM-friendly. Podes me dar umas dicas gerais sobre como fazer? Aliás, tem mais alguma coisa interessante no Labgeo sobre Porto Alegre além das ruas e praças? Eu não encontrei... De repente eles tem mais dados que não estão no site que eles poderiam nos dar (quiça o contorno das edificações), e com certeza eles ao menos responderiam nossos emails. Obrigado. Augusto. [1] http://www.ecologia.ufrgs.br/labgeo/arquivos/downloads/dados/Diagnostico_Ambiental_POA/cd/Base_cartografica/eixos_ruas.zip ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Começando com o Talk-br
Não mapeio com tanta frequência, nem sou tão experiente em geoprocessamento com o OpenStreetmap como vocês... meu nome é Marcos Antonio de Jesus Pereira, de Anhembi - SP. Espero me corrigir em alguns aspectos, aprender mais, me aprimorar e também contribuir de alguma forma. Tendo um celular com câmera e gps na mão (não é meu caso ainda, uso instrumentos separados) e tendo noções de conversão de arquivos track e poi para o formato gpx, além é claro de consultar bases de dados e mapas confiáveis, permitidos pelo OSM, é possível fazer muita coisa dentro da legalidade. É o que faço. A câmera é para registrar os pontos notáveis e situações de dúvida no local visitado. Já me fizeram muitos comentários sobre o google:... mapas google são uma coisa muito perigosa... servem apenas para eventual consulta e olha lá! Prefira imagens de satélite do Bing... o melhor mesmo é visitar o local (todas essas imagens estão desatualizadas por razões diversas e também por motivos de segurança - poderá estar deixando de mapear algo ou mapeando o que talvez não existe mais). O que fazemos já é algo muito primoroso. É só seguir em frente, na busca do melhor para todos. Marcos Pereira http://lattes.cnpq.br/7286163637647707 http://www.facebook.com/MarcosAntonioDeJesusPereira24649184827 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-de] Ab 21:00 RadioOSM Live
Hallo liebe OpenStreetMapper, heute Abend ab 21:00 sendet RadioOSM wieder Live. Ihr könnt mit uns und anderen Hörern im Chat sprechen: irc://irc.freenode.net/#Radio-OSM (Webchat: http://webchat.freenode.net?channels=Radio-OSM) und ab kurz vor 21:00 live auf http://streams.xenim.de/osm/ hören Alle weiteren Infos sowie alle alten Folgen findet ihr auf unserer Webseite http://podcast.openstreetmap.de Liebe Grüße, euer RadioOSM Team - Andi, Marc und Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Korrektur vom Schienenetz in Deutschland
Hallo Osm´ler, ** ** Wir nutzen die Fahrten der Bahnen in den Auskunftssystemen in Deutschland, Österreich, Schweiz, Norditalien und angrenzenden Ländern. Wir wollen die Wege der Züge auf den Gleisen routen. Wir haben hier einige Fehler gefunden, meist Stellen wo die Gleise nicht verbunden sind. ** ** Wir würden ein paar Korrekturen durchführen. Vereinzelt fehlen auch noch Gleise die wir ergänzen werden, in den Regionen wo wir uns auskennen. ** ** ** ** Viele Grüße Tracy ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur vom Schienenetz in Deutschland
On Wed, Sep 11, 2013 at 09:23:41AM +0200, Tracy Kasperczyk wrote: Hallo Osm´ler, ** ** Wir nutzen die Fahrten der Bahnen in den Auskunftssystemen in Deutschland, Österreich, Schweiz, Norditalien und angrenzenden Ländern. Wir wollen die Wege der Züge auf den Gleisen routen. Wir haben hier einige Fehler gefunden, meist Stellen wo die Gleise nicht verbunden sind. Habt ihr das manuell gefunden oder durch Automatismus? Das ganze wird ja eine dauerhafte Geschichte werden das OSM Daten korrigiert werden sollten. Wenn ihr die Community mit einbinden wollt dann bietet es sich an Fehlerstellen als Overlay im WMS Format anzubieten. Das lässt sich leicht als Hintergrund im JOSM einbinden und abarbeiten. Alternativ auch Debug layer wie die OSM Notes, den OSM Inspector der Geofabrik, keepright.at oder ähnliches. Wir würden ein paar Korrekturen durchführen. Vereinzelt fehlen auch noch Gleise die wir ergänzen werden, in den Regionen wo wir uns auskennen. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurzer Erfahrungsbericht: Garmin eTrex Vista HCx bei Radtour.
Am 10.09.2013 22:27, schrieb Manuel Reimer: die letzten drei Tage war mein Vater mit mir auf mehrtägiger Fahrradtour. Zur Unterstützung hatte ich diesmal ein mit OSM-Karten bestücktes Garmin eTrex Vista HCx dabei. Installiert war die Freizeitkarte, Über praktische Tipps, was man beim nächsten Mal besser machen könnte, würde ich mich sehr freuen. Hi, einige Anmerkungen: ich selber nutze das Nachfolgegerät eTrex 20. -Streckenberechnung: Ja, aufgrund des kleinen Speichers ist die maximale Wegberechnungslänge begrenzt. Wenn Du Glück hast schafft er mehr als 50 km. -Helligkeit: Hier gabs doch mal beim Vista den Bug, dass die maximale Helligkeit begrenzt war. Wurde durch einen Firmwareupdate behoben. -Routing: Bitte die besonderen Routingeinstellungen für die Freizeitkarte beachten (siehe Webseite der Karte). -Unbefestige Strassen vermeiden geht beim eTrex20 über: Einstellungen-Routing-Vermeidung einrichten-ungeteerte Straßen vermeiden. Beim Vista sollte es ähnlich gehen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurzer Erfahrungsbericht: Garmin eTrex Vista HCx bei Radtour.
Ich habe bis vor zwei Jahren ein etrex vista HCx fuer Radtouren benutzt. Die lengste war von Padua-Paris-London (1700km). Allerdings nicht mit real-time routing, sondern ausschliesslich mit tracks, die ich vorher auf dem computer erstellt hatte (am besten geeignet finde ich dafuer bikeroutetoaster.com). Auf dem Geraet hatte ich normalerweise velomap.orgKarten installiert. Ich bin am Anfang einfach die tracks nachgefahren. Spaeter habe ich dann einen Entdeckung gemacht (genau genommen irgendwo einen Hinweis im Internet), dass im kleinen alten etrex eine fantastische Funktion versteckt ist: wenn man einen track laedt und dann diesen mit trackback und Kompassnadel-Display abfaehrt, analysisert das etrex die Geometrie des track und produziert automatisch Fahrhinweise (voellig unabhaengig von der geladenen Landkarte). Man brauch nicht auf das Geraet zu schauen. Wenn man sich einer Kurve im track nehert, dann piept das Geraet etwa 50m vorher und schreibt eine Nachricht aufs display. Kurz darauf beginnt die grosse rote Kompassnadel sich in die Richtung zu drehen, die der track einschlaegt. Wenn man an der Kurve ist, zeigt die Nadel voll in die neue Richtung. Zu meiner grossen Verblueffung wusste Garmin (Italien) nichts von dieser Funktion im alten etrex. Sie haben mir's nicht geglaubt, bis ich ihnen eine genaue Beschreibung geschickt habe. Nun zum negativen: das Geraet wird nicht mehr gebaut. Ausserdem hat es zwei Einschraenkungen: maximal 500 Punkte per track und maximal 20 tracks. Das Nachfolgegeraet etrex 20/30 hat die Funktion nicht, aber ich glaube in einigen edge Modellen steckt sie drin. Volker 2013/9/10 Manuel Reimer manuel.s...@nurfuerspam.de Hallo, die letzten drei Tage war mein Vater mit mir auf mehrtägiger Fahrradtour. Zur Unterstützung hatte ich diesmal ein mit OSM-Karten bestücktes Garmin eTrex Vista HCx dabei. Installiert war die Freizeitkarte, weil greifbar und ohne Verrenkungen auch unter Linux auf das Gerät zu bekommen. Zu den Karten: Etwas schwierig ist die optimale Einstellung für ungeteerte Straßen meiden am Gerät zu finden. Wenn nicht angehakt, dann kann man wunderbar die Landschaft erkunden und man landet auch auf Wegen, die man sonst nie gefunden hätte. Gerne aber auch mal mit dem Fahrrad vor einer Treppe oder ähnlichem. Wenn die Option angehakt ist, dann wird man aber oft nicht auf Radwege geroutet. Liegt das am surface-Tag? Wird nur auf Radwege geroutet, die dann ein gewisses surface gesetzt haben? Ansonsten kann man zu den Karten an sich (in meinem Aktuellen Fall im Umkreis von Ostallgäu) hauptsächlich nur gutes sagen. Erstaunlich wie gut das Routing mit freien Karten funktioniert. Und erst Recht erstaunlich wie viele Details man in der Karte wiederfindet. Zum Gerät: Am Anfang hat es sehr gefrustet, dass das Garmin uns ständig auf Autobahnen routen wollte (Das Gerät war definitiv die ganze Zeit auf Fahrrad eingestellt). Erst später habe ich bemerkt, dass das Gerät wohl keine längeren Streckenabschnitte am Stück berechnen kann oder will. Ab einer gewissen Distanz (irgendwo zwischen 50 und 100 km) stockt das Gerät beim Berechnen bei 100%. Wenn die 100% mehrere Sekunden stehen bleiben ist das Ergebnis in aller Regel Mist und man landet im Worst-Case mit dem Fahrrad vor einer Autobahn-Auffahrt. Also haben wir immer eine Ortschaft nach der anderen ins Garmin getippt. So hat dann alles gut funktioniert. Schade nur, dass man keine längeren Abschnitte auf einmal berechnen lassen kann. Ist da was zu machen? Wie verhält sich das Gerät z.B. wenn man im Voraus mehrere Routenpunkte entlang der Strecke auf das Gerät lädt und dann anhand den Routenpunkten berechnen lässt? Gehen dann auch längere Schritte auf einmal? Der Bildschirm ist auch irre schwer zu lesen. Zumindest die Freizeitkarte hat sich im Alltag auf dem eTrex Vista HCx nicht bewährt. Auch mit maximaler Hintergrundbeleuchtung (die, nebenbei bemerkt, auch im maximalen Modus eher schwach ist) im dichten Stadtverkehr nur mit Mühen rechtzeitig abzulesen. Regelmäßig mussten wir rechts ranfahren um in Ruhe zu lesen wo wir hinsollen. Die lilane Hervorhebung der Straße ist bei den eher breiten Straßenzügen der Freizeitkarte nur schwer zu erkennen. Hier muss man wohl doch eher mit anderen Karten arbeiten. Sehr praktisch ist der einfache Akkuwechsel. Am zweiten Tag haben wir etwa um die Mittagszeit die Meldung Akku schwach bekommen. Bei der nächsten Rast also schnell neue rein und weiter. Über praktische Tipps, was man beim nächsten Mal besser machen könnte, würde ich mich sehr freuen. Gruß Manuel __**_ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.**org/listinfo/talk-dehttps://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 30C3 Call for Participation
osm-l...@deelkar.net wrote: Vielleicht auf einer Assembly mal die ganzen Hacks rund um OSM mehr hervorheben, also was man alles cooles mit den Daten anstellen kann/angestellt wird. Ich würde mich sehr über etwas zur Overpass-API overpass-turbo.eu freuen. Ala was kann man alles mit ihr machen, wie einfach ist es Daten aus OSM zu holen, etc. Ich glaube, das sowas bei vielen verschiedenen Leuten gut ankommen könnte. Viele Grüße, Hannes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur vom Schienenetz in Deutschland
Hallo Florian Vielen Dank für das Angebot. Leider geht das nur teilweise automatisch. ** ** Es gibt zwei Fehlermuster: ** ** Entweder der Zug fährt einen fürchterlichen Umweg oder das Programm findet überhaupt keinen Weg von A nach B. ** ** In beiden Fällen setzt man dann Zwangspunkte ein oder verkürzt den Weg, bis man die Stelle eingekreist hat, wo der Router nicht mehr weiter kommt. Wenn man den Fehler gefunden hat, ist die Reparatur meist nur eine Kleinigkeit, so dass sich ein Overlay dann nicht mehr lohnt. ** ** Allerdings haben wir noch ein anderes Problem. Das Tagging der Gleise ist nur wenig differenziert. Das hat zur Folge, dass der Router auch mal durch einen Bahnbetriebshof oder über einen Rangierbahnhof fährt. Wenn uns jemand sagen kann, wie wir Gleise erkennen und kennzeichnen können, die nicht für den Personenverkehr genutzt werden können, wäre das hilfreich. Viele Grüße Tracy Am 11. September 2013 09:36 schrieb Florian Lohoff f...@zz.de: On Wed, Sep 11, 2013 at 09:23:41AM +0200, Tracy Kasperczyk wrote: Hallo Osm´ler, ** ** Wir nutzen die Fahrten der Bahnen in den Auskunftssystemen in Deutschland, Österreich, Schweiz, Norditalien und angrenzenden Ländern. Wir wollen die Wege der Züge auf den Gleisen routen. Wir haben hier einige Fehler gefunden, meist Stellen wo die Gleise nicht verbunden sind. Habt ihr das manuell gefunden oder durch Automatismus? Das ganze wird ja eine dauerhafte Geschichte werden das OSM Daten korrigiert werden sollten. Wenn ihr die Community mit einbinden wollt dann bietet es sich an Fehlerstellen als Overlay im WMS Format anzubieten. Das lässt sich leicht als Hintergrund im JOSM einbinden und abarbeiten. Alternativ auch Debug layer wie die OSM Notes, den OSM Inspector der Geofabrik, keepright.at oder ähnliches. Wir würden ein paar Korrekturen durchführen. Vereinzelt fehlen auch noch Gleise die wir ergänzen werden, in den Regionen wo wir uns auskennen. Flo -- Florian Lohoff f...@zz.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIVAwUBUjAdjpDdQSDLCfIvAQhMFA/+JsTbq3h3KOo8ogPB89W/pJZbfVSGrO4d 0gTTnHuGIz7FQyBlzxDkrXVzjkb34ZL0WslR1thPAktqNO1JBWlNkOSwYAzs7d4x U+P+u0Vr4tzW/SAu0fgWEiILIamwynlaxm97CAyvePgzIy4TB4LBQD6vaCGmPnkD 9MnqUyxqKOFzvPmwj0jUxMrVXuJYtiXqvGZ+JDsQvdmd8OUNnPDmkT4rd0JRu+jq WxM2kM4wBCvMIjDE6hPvjPjv+elsaohUZS6cU8+Q1yL8HJaFq8si1tVY8/dVtezM XT1BWOhmgKZO2d4yJ4Pe6m1Ij1nCz5KIGFXt75ce6j3QE+fZFmqPmT4z9Jxs0x1+ /KwavbUQQ9wNiDRBzWQSFb4jgMJQPUf2q0ByjeZanYY9XZTcEMQqsALBkwn0+VfP gcp53e1uvB6zFkXSMmq/Qb9hzp7AO3/C2W0EzkTgLTuWBNn6/ngD44BP0U097417 dRekNOB/qS9anG8Wtr4TA52p25QVZZBxiU28vpt3WEdip5PxZACZ+khTY7SBKTwA 9j+xl4IEOy+zdRVC9hfSGbOfP5Up2tu8V/WNFGY1pBULv3Wj1ELmzmYGAOiOfhg8 zHLJCXuj3QIZFbMADlbpRsG845DShB8r2fEn6/SHrD4LiylDqFqOYUndsLJ7SGGm ZBdcFW71WOA= =l8DA -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur vom Schienenetz in Deutschland
Tracy Kasperczyk kasperc...@mentzdv.de wrote: Entweder der Zug fährt einen fürchterlichen Umweg oder das Programm findet überhaupt keinen Weg von A nach B. Den Routing view vom OSM Inspektor kennst Du? http://tools.geofabrik.de/osmi/?view=routinglon=11.58198lat=48.12790zoom=12 Insbesondere die Islands Geschichte könnte für euch interessant sein. Eventuelle infach mal die Geofabrik kontaktieren, ob sie das auch für Schienen einbauen kann. Gruss Sven P.S.: Inwiefern ist routing auf Schinen eigentlich überhaupt sinnvoll, wenn man ja sowieso nur zu diskreten Zeiten losfahren und (im Idealfall) auch akommen kann? -- How to prevent Java from forking? Use a spoon. (Found on http://slashdot.org) /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] Korrektur vom Schienenetz in Deutschland
Hallo, Allerdings haben wir noch ein anderes Problem. Das Tagging der Gleise ist nur wenig differenziert. Das hat zur Folge, dass der Router auch mal durch einen Bahnbetriebshof oder über einen Rangierbahnhof fährt. Wenn uns jemand sagen kann, wie wir Gleise erkennen und kennzeichnen können, die nicht für den Personenverkehr genutzt werden können, wäre das hilfreich. Im Zusammenhang mit meiner OpenRailwayMap habe ich vor einiger Zeit ein Taggingschema entwickelt, das bereits intensiv genutzt wird: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging#Gleis Ich habe auch eine Vorlage für JOSM erstellt, die das Tagging deutlich erleichtert: https://raw.github.com/rurseekatze/OpenRailwayMap/master/josm-presets/de.xml Gruß Alex 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] Korrektur vom Schienenetz in Deutschland
On 09/11/2013 11:43 AM, Sven Geggus wrote: Eventuelle infach mal die Geofabrik kontaktieren, ob sie das auch für Schienen einbauen kann. oder im Oktober mal vorbeischauen? http://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_October_2013 (Ok, München-Karlsruhe ist jetzt nicht sooo um die Ecke ...) -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 10.09.2013 11:35, schrieb Wolfgang Hinsch: Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen Multpolygone übereinander gelegt werden muss. Eine Universität mit den Unterteilungen in Fakultäten, Fachbereiche, Institute und Lehrstühle sowie zentralen Einrichtungen, die oft sehr verschachtelt sind, ist eine der kompliziertesten Institutionen. Wir können sie sicherlich nicht vollständig in OSM abbilden. Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. Die Untergliederungen würde ich nur als Punkt erfassen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11. September 2013 13:01 schrieb Stephan Wolff s.wo...@web.de: Am 10.09.2013 11:35, schrieb Wolfgang Hinsch: Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen Multpolygone übereinander gelegt werden muss. Eine Universität mit den Unterteilungen in Fakultäten, Fachbereiche, Institute und Lehrstühle sowie zentralen Einrichtungen, die oft sehr verschachtelt sind, ist eine der kompliziertesten Institutionen. Wir können sie sicherlich nicht vollständig in OSM abbilden. Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. Die Untergliederungen würde ich nur als Punkt erfassen. ich finde, mindestens die Fachbereiche und evtl. auch die Institute können wir schon hinbekommen, und das sind auch eher stabilere und für die Orientierung äusserst wichtige Informationen, Lehrstühle sind dagegen wirklich schon sehr detailiertes Micromapping. Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, wenn es mehrere Standorte gibt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11.09.2013 11:43, schrieb Alexander Matheisen: Im Zusammenhang mit meiner OpenRailwayMap […] Funktioniert da bereits etwas bahnspezifisches? Mit Firefox 23 auf GNU/Debian sehe ich auf http://www.openrailwaymap.org/ nur eine OpenStreetMap (langsam ladend, mit höhenschattierung, wahlweise in Grau oder Farbe, und per default in dieser MapQuest-Darstellung die Autobahnen sehr betont). Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIwVU0ACgkQbtUV+xsoLppm4QCgxX/NsDp1l209f5kFASlP+0UL sFUAn24r7lKPJk6KmHLay7ZOmFpaJG6U =kCcz -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11.09.2013 13:07, schrieb Martin Koppenhoefer: ich finde, mindestens die Fachbereiche und evtl. auch die Institute können wir schon hinbekommen, und das sind auch eher stabilere und für die Orientierung äusserst wichtige Informationen, Lehrstühle sind dagegen wirklich schon sehr detailiertes Micromapping. Aber ist das geografisch eindeutig? Beispiel hier in Paderborn: Fakultäten: - Kulturwissenschaften: Verteilt über den Hauptcampus auf mehrere nicht-zusammenhängende Gebäude, dazu die Aussenstelle in Detmold - Wirtschaftswissenschaften: Verteilt auf dem Campus, und Teile der Wirtschaftsinformatik am Standort Fürstenallee - Naturwissenschaften: verteilt auf dem Campus und Sportgelände - Maschinenbau: das dürfte mit die kompakteste Fakultät sein - E-technik, Informatik, Mathematik: Campus (weitgehend zusammenhängend) + Fürstenallee Auf Institutsebene weiß ich von den Wirtschaftswissenschaften und der BWL, dass die deutlich verteilt sind über mehrere Gebäude. Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, wenn es mehrere Standorte gibt. Oft reicht aber eben auch nicht Fakultät Informatik, sondern Büro von Prof. Meier, Fakultät für Informatik, Uni Buxtehude. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11. September 2013 13:44 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 11.09.2013 13:07, schrieb Martin Koppenhoefer: ich finde, mindestens die Fachbereiche und evtl. auch die Institute können wir schon hinbekommen, und das sind auch eher stabilere und für die Orientierung äusserst wichtige Informationen, Lehrstühle sind dagegen wirklich schon sehr detailiertes Micromapping. Aber ist das geografisch eindeutig? Beispiel hier in Paderborn: Fakultäten: - Kulturwissenschaften: Verteilt über den Hauptcampus auf mehrere nicht-zusammenhängende Gebäude, dazu die Aussenstelle in Detmold - Wirtschaftswissenschaften: Verteilt auf dem Campus, und Teile der Wirtschaftsinformatik am Standort Fürstenallee - Naturwissenschaften: verteilt auf dem Campus und Sportgelände - Maschinenbau: das dürfte mit die kompakteste Fakultät sein - E-technik, Informatik, Mathematik: Campus (weitgehend zusammenhängend) + Fürstenallee zugegeben, (mittlerweile) gibt es eher wenige und allgemeine Fakultäten, daher wäre Institutsebene wohl angebracht. Auf Institutsebene weiß ich von den Wirtschaftswissenschaften und der BWL, dass die deutlich verteilt sind über mehrere Gebäude. - site relation, evtl. muss man vielleicht doch auf Lehrstuhlebene gehen? Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, wenn es mehrere Standorte gibt. Oft reicht aber eben auch nicht Fakultät Informatik, sondern Büro von Prof. Meier, Fakultät für Informatik, Uni Buxtehude. ja klar, wenn man ein bestimmtes Anliegen hat, dann braucht man normalerweise neben dem Gebäude auch eine Zimmernummer, der Gedanke war, dass man mit OSM wenigstens in die Nähe kommt, wo man dann den richtigen Pförtner fragen kann, wo man genau hin muss. Wenn das aber auch so nicht (in allen Fällen) funktioniert, dann ist bei Universitäten vielleicht noch am ehesten eine Chance (aufgrund unserer Mapper-Struktur), dass man die Informationen detailliert und aktuell anbieten kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11. September 2013 13:54 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Auf Institutsebene weiß ich von den Wirtschaftswissenschaften und der BWL, dass die deutlich verteilt sind über mehrere Gebäude. - site relation, evtl. muss man vielleicht doch auf Lehrstuhlebene gehen? sorry, Fachgebiet wäre da wohl die nächste Stufe. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Shared Nodes bei landuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Zusammen, ich habe mal eine Frage bei der ich mir bis jetzt immer unsicher war. Es kommt ja nicht gerade selten vor das zum Beispiel landuse=residential und landuse=grass direkt aneinander liegen. Nun kommt es oft vor das zwischen den einzellnen landuse areas Platz gelassen wird. Ich denke es wäre bestimmt sauberer durch shared nodes die Areas miteinander zu verbinden. Ist das legitim oder wäre das falsch oder unsauber? Ich bin mir da wirklich unsicher und dachte ich frage mal nach. Nach dem rendern sieht das ja ganz ok aus... liebe Grüße, Marvin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSMG6NAAoJEJA5GTOuzd280jIH/2zOnMFG9bVraXu8XcgocXFD Hi0wB9PDKV0WshvscZjuuoYg/C4itBDOhtSWwSlKPjz1baJL51liMu/0vcTjc67i oZL2StAswdt53iEj5F4ncpVAwblXsOZEmX17eP9NNCFSDsdUIOFFeCFDMwZLcBZP l7WLAoJtrEU5mWMCGlzpb6/nuhMFyCkNMzfTLEArFIENsEHhEtbJhvyn/iVC1amx omygMzK5qtRB/ojuEOh9eMICnAa1/7TQOgBI0lFWIXGVHBgORdw4h0H5uhAeOmy6 LjYZrk7L6YySq1E8uSfBW+ykrABksPELPYFt2V9tJVI6F4UP/HCuUsbA8kG6Li4= =mh1u -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11. September 2013 15:22 schrieb Marvin Preuss mar...@xsteadfastx.org: Es kommt ja nicht gerade selten vor das zum Beispiel landuse=residential und landuse=grass direkt aneinander liegen. Nun kommt es oft vor das zwischen den einzellnen landuse areas Platz gelassen wird. Ich denke es wäre bestimmt sauberer durch shared nodes die Areas miteinander zu verbinden. Ist das legitim oder wäre das falsch oder unsauber? Ich bin mir da wirklich unsicher und dachte ich frage mal nach. Nach dem rendern sieht das ja ganz ok aus.. Grundsätzlich sollten direkt angrenzende Objekte auch in OSM verbunden sein und bei solchen, bei denen es im echten Leben einen kleinen Spalt gibt auch in OSM keine direkte Verbindung bestehen, das gilt für alle Objekte. Davon abgesehen würde ich grass eher als landcover ansehen denn als landuse/Nutzung. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Hallo Marvin, die Frage ist eine der häufigsten Fragen bei OSM, und es gibt keine eindeutige Antwort dazu. Vorteil von shared-Nodes: Es gibt keine Lücken, auch auf hohen zoomstufen nicht. Nachteile von shared-Nodes: 1) Ist wirklich nichts dazwischen? Gibt es wirklich keinen Graben Wiese und Acker, keine Brache zwischen Acker und ortsgebiet (residential)? Je nachdem, wie detailliert man mapped, muss man fast immmer einräumen, dass man dazwischen doch noch was eintragen müsste. 2) Was, wenn sich das Ortsgebiet ausdehnt, aber landuse=grass sich nicht ändert? Dann sind Anpassungen wesentlich einfacher, wenn keine Nodes gemeinsam genutzt worden sind, weil man dann nicht die Wege erst mühsam voneinander trennen muss. Insbesondere kommt das z.B. vor, wenn der Weg am Waldrand noch fehlt, aber Waldrand und Acker sich nodes teilen oder so. Insofern: beides geht, die meisten, die sich hier auf der Mailingliste normalerweise dazu äußern, bevorzugen die getrennte Variante, würd ich mal so zusammenfassen (ohne gezählt zu haben) Gruß Peter Am 11.09.2013 15:22, schrieb Marvin Preuss: Hallo Zusammen, ich habe mal eine Frage bei der ich mir bis jetzt immer unsicher war. Es kommt ja nicht gerade selten vor das zum Beispiel landuse=residential und landuse=grass direkt aneinander liegen. Nun kommt es oft vor das zwischen den einzellnen landuse areas Platz gelassen wird. Ich denke es wäre bestimmt sauberer durch shared nodes die Areas miteinander zu verbinden. Ist das legitim oder wäre das falsch oder unsauber? Ich bin mir da wirklich unsicher und dachte ich frage mal nach. Nach dem rendern sieht das ja ganz ok aus... liebe Grüße, Marvin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Hi, On Wed, Sep 11, 2013 at 03:22:22PM +0200, Marvin Preuss wrote: Hallo Zusammen, ich habe mal eine Frage bei der ich mir bis jetzt immer unsicher war. Es kommt ja nicht gerade selten vor das zum Beispiel landuse=residential und landuse=grass direkt aneinander liegen. Nun kommt es oft vor das zwischen den einzellnen landuse areas Platz gelassen wird. Ich denke es wäre bestimmt sauberer durch shared nodes die Areas miteinander zu verbinden. Ist das legitim oder wäre das falsch oder unsauber? Ich bin mir da wirklich unsicher und dachte ich frage mal nach. Nach dem rendern sieht das ja ganz ok aus... Ich halte das fuer sauber landuses wenn sie denn wirklich aneinander grenzen mit shared nodes zu bauen. landuse=farmland und landuse=meadow liegen ja gerne direkt nebeneinander. Wenn noch ein track dazwischen durchgeht dann teilen sich die flaechen nicht die nodes, weder miteinander noch mit dem track. Anders als bei Straßen haben landuses ja exakt die geometrische ausdehnung die die nodes andeuten, wohingegen eine landuse die bis zum Straßennode geht ja vermeindlich bis zur Straßenmitte gehen würde. Was ich immer vermeide ist unterschiedliche typen von flaechen ihre nodes sharen zu lassen. D.h. landuser/leisure, landuse/amenity oder ganz wichtig landuse/highway teilen sich bei mir nie die nodes. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
On Wed, Sep 11, 2013 at 03:33:24PM +0200, Peter Wendorff wrote: Insofern: beides geht, die meisten, die sich hier auf der Mailingliste normalerweise dazu äußern, bevorzugen die getrennte Variante, würd ich mal so zusammenfassen (ohne gezählt zu haben) Genau - beides geht - landuse/landuse verbinden finde ich okay. Ganz unübersichtlich wird das wenn landuse/highway und noch moeglicherweise darueberliegende Elemente wie ein Parkplatz oder ein Sportplatz sich die Nodes teilen. Meist habe ich dann entweder keine lust mehr was dran zu aendern oder wenn ich einen radikalen tag habe loesche ich das und trage es alles neu ein. Editieren im sinne von inkrementell dinge geradeziehen kann man bei so einem durcheinander von Flaechen meist vergessen - bzw - mir fehlt fuer so einen murks echt die Geduld. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11. September 2013 15:52 schrieb Ronnie Soak chaoschaos0...@googlemail.com: oder wenn das, was noch dazwischen ist, üblicherweise nicht gemappt wird oder üblicherweise einer der Flächen hinzugerechnet wird. (Residential kann also z.B. durchaus direkt an einen Wald Grenzen, wenn der Weg am Waldrand dem Wohngebiet zuzurechnen ist.) im Prinzip zu allem +1 bis auf diesen Absatz. Erstens mappen wir üblicherweise Wege (d.h. Du widersprichst Dir hier selbst ein bisschen), und zweitens sind Straßen und Wege die nicht auf Grundstücken verlaufen besser nicht im landuse enthalten. Zugegeben ist es erstmal einfacher, das nur grob zu betreiben und Wege durch den Wald einfach drüber zu legen, aber gerade bei Wohngebieten halte ich es schon für machbar, zwischen Grundstücken (landuse) und Straßen (öffentliches Allgemeingut, eben keine Wohnnutzung sondern Nutzung als Straße) zu unterscheiden. Das führt zwar zunächst zu mehr Arbeit, ist aber für weiteres Bearbeiten später einfacher und enthält auch viel mehr Informationen (Grundstücksgrenzen zur Straße, rechtliche Fläche der Straßennutzung). Ein Wohngebiet im Sinne eines Siedlungsteils mit Namen mappe ich gar nicht mit landuse sondern als place=neighbourhood, name=foo. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am Mittwoch, den 11.09.2013, 13:34 +0200 schrieb Philipp Klaus Krause: Am 11.09.2013 11:43, schrieb Alexander Matheisen: Im Zusammenhang mit meiner OpenRailwayMap […] Funktioniert da bereits etwas bahnspezifisches? Mit Firefox 23 auf GNU/Debian sehe ich auf http://www.openrailwaymap.org/ nur eine OpenStreetMap (langsam ladend, mit höhenschattierung, wahlweise in Grau oder Farbe, und per default in dieser MapQuest-Darstellung die Autobahnen sehr betont). Du hast mich gerade auf einen Bug aufmerksam gemacht, den ich bisher noch nicht entdeckt habe. Bei meiner letzten Codeänderung hatte ich wohl einen Variablennamen falsch geschrieben... Jetzt sollte wieder alles funktionieren. Die Karte ist soweit fertig und benutzbar, wenn auch besonders in niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser gerendert wird. Gruß Alex 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] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am 11.09.2013 13:34, schrieb Philipp Klaus Krause: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11.09.2013 11:43, schrieb Alexander Matheisen: Im Zusammenhang mit meiner OpenRailwayMap […] Funktioniert da bereits etwas bahnspezifisches? Mit Firefox 23 auf GNU/Debian sehe ich auf http://www.openrailwaymap.org/ nur eine OpenStreetMap (langsam ladend, mit höhenschattierung, wahlweise in Grau oder Farbe, und per default in dieser MapQuest-Darstellung die Autobahnen sehr betont). Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIwVU0ACgkQbtUV+xsoLppm4QCgxX/NsDp1l209f5kFASlP+0UL sFUAn24r7lKPJk6KmHLay7ZOmFpaJG6U =kCcz -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de Servus, auf Fedora wurde es einwandfrei dargestellt (ebenfalls FF). Lg ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
On Wed, Sep 11, 2013 at 03:52:28PM +0200, Ronnie Soak wrote: Ich nutze ebenfalls gemeinsame nodes, wenn die Flächen wirklich aneinandergrenzen oder wenn das, was noch dazwischen ist, üblicherweise nicht gemappt wird oder üblicherweise einer der Flächen hinzugerechnet wird. Das mit dem üblicherweise ist gefährlich :) Es gab da durchaus mal Ansätze Straßen als Flächen (zusätzlich) zu erfassen. Also was heute noch unüblich sein kann kann morgen schon total hip sein und wieder horden von gelangweilten mappern beschäftigen ... Ich nehme lieber lücken in der Karte hin als irgendwas zu stark zu abstrahieren. Hat natürlich alles seine Grenzen - Gesunder Menschenverstand und so ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
On Wednesday 11 September 2013, Marvin Preuss wrote: Hallo Zusammen, ich habe mal eine Frage bei der ich mir bis jetzt immer unsicher war. Es kommt ja nicht gerade selten vor das zum Beispiel landuse=residential und landuse=grass direkt aneinander liegen. Nun kommt es oft vor das zwischen den einzellnen landuse areas Platz gelassen wird. Ich denke es wäre bestimmt sauberer durch shared nodes die Areas miteinander zu verbinden. Ist das legitim oder wäre das falsch oder unsauber? Die eigentliche theologische Streitfrage ist dann aber, ob man die gemeinsamen Kanten als ein way in zwei Multipolygonen mappt, oder zwei ways mit gemeinsamen nodes... Ungeachtet der Frage was besser ist - es gibt bei solchen Lücken auch einige Beispiele, die schon für sich eine gewisse Ästhetik bieten: http://www.openstreetmap.org/#map=13/46.2604/38.8271 Grüße, -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11. September 2013 17:37 schrieb Christoph Hormann chris_horm...@gmx.de : Die eigentliche theologische Streitfrage ist dann aber, ob man die gemeinsamen Kanten als ein way in zwei Multipolygonen mappt, oder zwei ways mit gemeinsamen nodes... ist im Prinzip egal, man kann sich danach richten, was weniger Komplexität und Redundanz schafft (d.h. in Abhängigkeit von der Anzahl der Nodes der überlappenden Kanten agieren) Ungeachtet der Frage was besser ist - es gibt bei solchen Lücken auch einige Beispiele, die schon für sich eine gewisse Ästhetik bieten: http://www.openstreetmap.org/#map=13/46.2604/38.8271 wobei es da ja auch in der Realität zwischen den Feldern (wie meistens) kleine Lücken gibt (sieht man in Bing). Ungeachtet der Ästhetik hat die Form der Felder an sich m.E. auch einen höheren Informationsgehalt als die reine Information, dass es sich überhaupt um ein Feld handelt. Weniger theologisch ist die Sache bei Gebäuden, da kann man i.d.R. zweifelsfrei entscheiden, ob sie angebaut oder mit Zwischenraum sind. Tendenziell kann man evtl. sagen, dass in der Stadt eher keine Lücken zwischen den Flächen sind, während es sie auf dem Land eher gibt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11.09.2013 15:36, schrieb Florian Lohoff: landuse=farmland und landuse=meadow liegen ja gerne direkt nebeneinander. Wenn noch ein track dazwischen durchgeht dann teilen sich die flaechen nicht die nodes, weder miteinander noch mit dem track. Anders als bei Straßen haben landuses ja exakt die geometrische ausdehnung die die nodes andeuten, wohingegen eine landuse die bis zum Straßennode geht ja vermeindlich bis zur Straßenmitte gehen würde. Weit überwiegend wird landuse als Gebiet (Bau-, Gewerbe-, Wohngebiet) verwendet, das Wege und Nebenstraßen einschließt. Der Satz im Wiki Im Idealfall endet die eingezeichnete Landnutzung an der Grundstücksgrenze. findet sich nur in der deutschen Version und wurde erst im Mai 2013 eingefügt. Was ich immer vermeide ist unterschiedliche typen von flaechen ihre nodes sharen zu lassen. D.h. landuser/leisure, landuse/amenity oder ganz wichtig landuse/highway teilen sich bei mir nie die nodes. Warum? Selbst wenn man landuse als Grundstücke definiert, haben Wohngrundstücke zu Schulen (amenity) und Parks (leisure) oftmals gemeinsame Grenzen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11.09.2013 16:22, schrieb Alexander Matheisen: Am Mittwoch, den 11.09.2013, 13:34 +0200 schrieb Philipp Klaus Krause: Am 11.09.2013 11:43, schrieb Alexander Matheisen: Im Zusammenhang mit meiner OpenRailwayMap […] Funktioniert da bereits etwas bahnspezifisches? Mit Firefox 23 auf GNU/Debian sehe ich auf http://www.openrailwaymap.org/ nur eine OpenStreetMap (langsam ladend, mit höhenschattierung, wahlweise in Grau oder Farbe, und per default in dieser MapQuest-Darstellung die Autobahnen sehr betont). Du hast mich gerade auf einen Bug aufmerksam gemacht, den ich bisher noch nicht entdeckt habe. Bei meiner letzten Codeänderung hatte ich wohl einen Variablennamen falsch geschrieben... Jetzt sollte wieder alles funktionieren. Die Karte ist soweit fertig und benutzbar, wenn auch besonders in niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser gerendert wird. Danke. Eine Eisenbahnkarte auf OSM-Basis scheint mir eine sehr gute Idee. Und abgesehen von der Langsamkeit ist die gefällt mir die Karte auch. Ist es geplant, da noch weitere Informationen einblendbar zu machen (z.B. Oberstromgrenzwerte, Neigetechnik, etc)? Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIwqOQACgkQbtUV+xsoLpoFcACfVEcbgAbxics8HdRsKgQNEch5 gDEAnixszkOYcq3fKS85WE00hdOeW5x4 =6rSK -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11.09.2013 19:59, schrieb Florian Lohoff: Es wird irgendwann zweit das die Editoren layer lernen d.h. landuse kommt in einen eigenen layer, highway kommt in einen layer etc. Über den Filter in JOSM geht das ja im Prinzip schon. Aber halt nur wenn die Objekte nicht zusammengeklebt sind. Grüße Chris (der auch nur Objekte gleichen Typs zusammenklebt) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11. September 2013 19:25 schrieb Stephan Wolff s.wo...@web.de: Weit überwiegend wird landuse als Gebiet (Bau-, Gewerbe-, Wohngebiet) verwendet, das Wege und Nebenstraßen einschließt. Ja, das ist in Deutschland zumindest überwiegend (noch) so, aber das könnte man ja ändern, wenn ein Wille da ist. M.E. sind wir beim landuse noch relativ am Anfang, oft sind komplette Städte oder Ortschaften durchgehend mit landuse=residential getaggt, das liegt aber historisch vor allem daran, dass place als Fläche nicht gerendert wurde/wird, und wirklich Sinn macht es nicht, weil es auch dazu führt, dass man den Leuten das detaillierte Nutzungsmappen verbieten muss. Gebiet ist jegliche größere Fläche, Gewerbe- bzw. Wohngebiet sind Siedlungsteile, d.h. abgegrenzte/abgrenzbare Teile einer Siedlung (Stadt/Dorf/etc.) mit eigenem Namen und Identität. M.E. ist place dafür der richtige Tag, ob es dann ein Gewerbe oder ein Wohngebiet ist, sieht man wunderbar an den enthaltenen landuses. Gruß Martin PS: Sorry für die vielen Anführungszeichen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Danke. Eine Eisenbahnkarte auf OSM-Basis scheint mir eine sehr gute Idee. Und abgesehen von der Langsamkeit ist die gefällt mir die Karte auch. Ist es geplant, da noch weitere Informationen einblendbar zu machen (z.B. Oberstromgrenzwerte, Neigetechnik, etc)? Ja, die Kartenstyles sollen nach und nach erweitert werden. Konkret geplant sind bereits Ansichten für Elektrifizierung und Spurweite, aber es können natürlich noch unzählige weitere Stile erstellt werden. Konkrete Vorschläge sind gerne gesehen und können per Mail oder als Github Issue mitgeteilt werden. Gruß Alex 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] Shared Nodes bei landuse
Hallo Flo, Es wird irgendwann zeit das die Editoren layer lernen d.h. landuse kommt in einen eigenen layer, highway kommt in einen layer etc. :-) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taggingfrage (mal wieder)
Moin, Ist eine LBS-Filiale (ohne Sparkassenautomat o.ä.) eine amenity=bank oder doch eher eine office=accountant? Ist eine Filiale der Deutschen Vermögensberatung eine office=accountant oder doch was anderes? MfG Andreas -- Andreas Neumann http://stadtplan-ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am Mittwoch, den 11.09.2013, 14:55 + schrieb Sven Geggus: Alexander Matheisen alexandermathei...@ish.de wrote: Die Karte ist soweit fertig und benutzbar, wenn auch besonders in niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser gerendert wird. Da man die Features ohnehin nicht anklicken kann. Spricht was dagegen mit Mapserver oder Mapnik live aus der serverseitigen Datenbank zu rendern? Grundsätzlich spricht nichts dagegen. Für KothicJS und gegen einen herkömmlichen Tileserver hatte ich mich aus folgenden Gründen entschieden: * Geringerer Rechenaufwand auf dem Server durch Rendering im Client; weniger Speicherplatzbedarf auf dem Server, da für mehrere angebotene Renderingstyles nicht jede Kachel mehrfach abgelegt werden muss * Möglichkeit des Stylewechsels und Sichtbarkeit von Änderungen am Renderingstyle, ohne die Kacheln neu rendern zu müssen Liverendering mit Mapserver oder Mapnik habe ich bisher noch nicht ausprobiert. Bis auf den höheren Rechenaufwand auf dem Server würden sich damit scheinbar auch meine Anforderungen erfüllen lassen. Wie sich beide Lösungen hinsichtlich der Performance verhalten, müsste man ausprobieren. Was ich auf die Schnelle nicht gefunden habe ist eine Legende. Die Anwendung ist ja auch noch nicht komplett fertig, sonst hätte ich hier auch schon mehr Werbung gemacht. Ach ja und railway = funicular scheint nicht dargestellt zu werden, oder hab ich da was vergessen zu taggen? Dass Standseilbahnen nicht dargestellt werden, ist so gewollt. Die Karte beschränkt sich nämlich auf die richtigen Eisenbahnen, also schienengebundene und aus eigener Kraft fahrende Verkehrsmittel. Siehe http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Projektbeschreibung. Gruß Alex 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] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Alexander Matheisen alexandermathei...@ish.de wrote: Liverendering mit Mapserver oder Mapnik habe ich bisher noch nicht ausprobiert. In kleinen Zoomleveln ist das kein Problem. Der OSM Inspektor macht das zum Beispiel so. Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /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] Gebäude, Grundstücke und Institutionen
Am 11.09.2013 13:07, schrieb Martin Koppenhoefer: Am 11. September 2013 13:01 schrieb Stephan Wolff s.wo...@web.de: Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. Die Untergliederungen würde ich nur als Punkt erfassen. ich finde, mindestens die Fachbereiche und evtl. auch die Institute können wir schon hinbekommen, und das sind auch eher stabilere und für die Orientierung äusserst wichtige Informationen, [] Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, wenn es mehrere Standorte gibt. Eine Universität oder ein Uniklinikum lassen sich meist gut als Fläche definieren. Die einzelnen Institute und Fachkliniken sind aber oft so kleinteilig untereinander und mit Gemeinschaftsräumen vermischt, dass eine Flächenerfassung kaum möglich ist. Zudem gibt es oft mehrstöckige Gebäude mit unterschiedlicher Nutzung auf jeder Ebene. Das Institute und Fachkliniken in die OSM-Datenbank gehören, wird hoffentlich nicht bezweifelt. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Jetzt RadioOSM Live
Hallo liebe OpenStreetMapper, in kürze sendet RadioOSM wieder Live. Ihr könnt uns auf http://streams.xenim.de/osm/ Live hören und mit uns und anderen Hörern im Chat sprechen: irc://irc.freenode.net/#Radio-OSM (Webchat: http://webchat.freenode.net?channels=Radio-OSM) Alle weiteren Infos sowie alle alten Folgen findet ihr auf unserer Webseite http://podcast.openstreetmap.de Liebe Grüße, euer RadioOSM Team - Andi, Marc und Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Alexander Matheisen alexandermathei...@ish.de wrote: Die Karte ist soweit fertig und benutzbar, wenn auch besonders in niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser gerendert wird. Da man die Features ohnehin nicht anklicken kann. Spricht was dagegen mit Mapserver oder Mapnik live aus der serverseitigen Datenbank zu rendern? Was ich auf die Schnelle nicht gefunden habe ist eine Legende. Ach ja und railway = funicular scheint nicht dargestellt zu werden, oder hab ich da was vergessen zu taggen? Gruss Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /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] Shared Nodes bei landuse
On Wed, Sep 11, 2013 at 07:25:03PM +0200, Stephan Wolff wrote: Was ich immer vermeide ist unterschiedliche typen von flaechen ihre nodes sharen zu lassen. D.h. landuser/leisure, landuse/amenity oder ganz wichtig landuse/highway teilen sich bei mir nie die nodes. Warum? Selbst wenn man landuse als Grundstücke definiert, haben Wohngrundstücke zu Schulen (amenity) und Parks (leisure) oftmals gemeinsame Grenzen. Die Flaeche der Schule gehört zum Wohngebiet - ja - Das heisst aber nicht das die Aussenkante des Wohngebietes gleich der Aussenkante der Schule sein muss. Wenn dann noch ein Fußweg drumherum führt gehört der zwar zum Wohngebiet aber nicht mehr zur Schule. Dieses ganze Mixen von Nodes/Ways fuer unterschiedliche zwecke halte ich im Sinne der Pflegbarkeit fuer eine vollkatastrophe. Wie ich schon sagte - Ich denke ich bin schon ein paar Jahre dabei und beherrsche JOSM - aber wenn ich auf so ein Kuddelmuddel treffe dann vergeht mir die Lust da irgendwas zu reparieren. Geometrien halbwegs beherrschbar zu halten wenn buildings, landuses, amenity, und highways irgendwelche nodes oder ways sharen ist unmoeglich. Der nächste malt da noch eine postcode oder admin boundary durch und das chaos ist perfekt. Meist erkennt man die Stellen bei denen sich soetwas haeuft gut bei keepright an der erhöhten Anzahl von bugs. Es wird irgendwann zweit das die Editoren layer lernen d.h. landuse kommt in einen eigenen layer, highway kommt in einen layer etc. Wenn mir das schon so geht dann kann der unerfahrene mapper da nur etwas kaputt machen oder frustriert aufgeben. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kurzer Erfahrungsbericht: Garmin eTrex Vista HCx bei Radtour.
Das HCx unterstützt lediglich 256 Farben. Das Standard-TYP-File der Freizeitkarten berücksichtigt dies nicht. D.h. die dort verwendeten Farben werden irgendwie auf die 256 verfügbaren Farben gemappt. Waldflächen sind dadurch z.B. wenig ansehnlich blaugrau. Es gibt alternative TYP-Files ... keines davon berücksichtigt jedoch die spezielle Farbpalette des HCx. Anders ausgedrückt: Ein speziell auf die Farbpalette und geringe Displayauflösung ausgelegtes TYP-File, dürfte signifikante Verbesserungen bringen ... Gruß Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Kurzer-Erfahrungsbericht-Garmin-eTrex-Vista-HCx-bei-Radtour-tp5777050p5777218.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingfrage (mal wieder)
oder building_association / building_society für die LBS? accountant ist so allgemein und klingt eher nach Buchhaltungsdienstleister aka Steuerberater... Die Deutsche Vermögensberatung ist laut Wikipedia eine investment company: http://en.wikipedia.org/wiki/Deutsche_Verm%C3%B6gensberatung Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am 11.09.2013 17:55, schrieb Alexander Matheisen: Ach ja und railway = funicular scheint nicht dargestellt zu werden, oder hab ich da was vergessen zu taggen? Dass Standseilbahnen nicht dargestellt werden, ist so gewollt. Die Karte beschränkt sich nämlich auf die richtigen Eisenbahnen, also schienengebundene und aus eigener Kraft fahrende Verkehrsmittel. Warum diese Beschränkung? Damit fehlen auch Verbindungsglieder zwischen Eisenbahnen, insbesondere wenn sie als Transportmittel für Eisenbahnwagen eingesetzt werden. http://de.wikipedia.org/w/index.php?title=Datei:OBS_Aufsetzwagen_ex_EB_188_513.jpgfiletimestamp=20071118162129; http://de.wikipedia.org/wiki/Parc_d%E2%80%99Attractions_du_Ch%C3%A2telard Gruß Garry ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 30C3 Call for Participation
Am 11.09.2013 10:36, schrieb Johannes Kröger: Ich würde mich sehr über etwas zur Overpass-API overpass-turbo.eu freuen. Ala was kann man alles mit ihr machen, wie einfach ist es Daten aus OSM zu holen, etc. Ich glaube, das sowas bei vielen verschiedenen Leuten gut ankommen könnte. Ich verweise in dem Zusammenhang u.A. auf die Videos von der FOSSGIS (IIRC auch 2012, sicher aber 2013 http://wiki.openstreetmap.org/wiki/FOSSGIS_2013 ) oder von der gerade zu Ende gegangenen SOTM 2013. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Marvin Preuss marvin at xsteadfastx.org writes: Es kommt ja nicht gerade selten vor das zum Beispiel landuse=residential und landuse=grass direkt aneinander liegen. Nun kommt es oft vor das zwischen den einzellnen landuse areas Platz gelassen wird. Ich denke es wäre bestimmt sauberer durch shared nodes die Areas miteinander zu verbinden. Ist das legitim oder wäre das falsch oder unsauber? Es ist definitiv falsch, wenn du in irgendeinem schon gut gemappten Gebiet jetzt stundenlang irgendwelche sauber getrennten Flächen zusammenklebst. Das ist auch dann falsch, wenn die Flächen deiner Ansicht nach genau angrenzen. Zumindest ich bin der Meinung, dass ein solches Verhalten ein Verwarnungsgrund wäre und wenn es in meiner Region passiert, dann würde ich all diese Changesets zurücksetzen lassen. Ich bin mir da wirklich unsicher und dachte ich frage mal nach. Nach dem rendern sieht das ja ganz ok aus... Wenn man die Flächen bevorzugt an Wegen trennt und die Nodes nah genug an den Weg ranzieht, dann fällt die Trennung im Rendering genau so wenig auf. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Nuovo geocoder OSM
Il 11/09/2013 02:45, Giacomo Boschi ha scritto: Prima di imbarcarci in un'impresa che richiede diverse ore-uomo, mi piacerebbe capire come mai un motore di ricerca non riesce a gestire un caso così banale. Voglio dire, tutto si riduce a dare come risultato l'elemento parola1 parola2 parola3 quando si immette come stringa di ricerca parola1 parola3. +1 se serve, come programmatore pc/plc, posso dare una mano tecnica ma servono i sorgenti del motore di ricerca -- Stefano Fraccaro Web: http://www.stefanofraccaro.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Nuovo geocoder OSM
L'ho segnalato in ml appena tornato da sotm ... ma forse poi il thread è andato più sul tool che lo usa che sul geocoder Sì maurizio scusami, me ne sono accorto poco dopo aver postato :( speravo che nessuno rispondesse al mio thread così da portare avanti la discussione sul tuo. ho notato anche io che il discorso si era spostato sul programma che utilizza il geocoder...per carità, il programma non è male ma a me ha impressionato proprio il geocoder (che mi piacerebbe venisse integrato dentro openstreetmap.org una volta pronto). Per quanto riguarda il geocoder photon credo che gran parte dei problemi per noi sia dovuti al fatto che al momento la lingua italiana non sia supportata (al momento solo inglese e tedesco). per quanto concerne i nomi delle vie ha qualche difficoltà se non si inseriscono tutte le stringhe che compongono il nome, ma qualcosa trova e solitamente spunta durante la ricerca dinamica nella lista sotto la barra di ricerca. è ancora un po' da affinare per quanto concerne il ranking in questa lista (se metto milano il primo risultato è Fondocasa, Como (???), il risultato corretto è solo in terza posizione) ma credo siano problemi solo di giovinezza e sono convinto che sia più che possibile migliorarlo per quanto riguarda il tradurre il geocoder Photon sarei disponibile io...ma devo capire bene dove dovrei mettere mano e se ne parlerebbe comunque solo dopo settembre (tra l'altro sono impegnato anche nella traduzione di altri progetti che mi prenderanno parecchio tempo). scusami ancora per il doppio thread ;) - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Nuovo-geocoder-OSM-tp5776920p5777080.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Nuovo geocoder OSM
Il 09/11/2013 07:52 AM, Maurizio Napolitano scrisse:
L'ho segnalato in ml appena tornato da sotm ... ma forse poi il thread è
andato più sul tool che lo usa che sul geocoder
In ogni caso durante la presentazione è stato fatto presente che
funziona bene con l'inglese e il tedesco
Per l'italiano si tratta di lavorare sulla configurazione di solr
Visto il gran numero di persone che lamentano di un geocoder italiano
ben fatto credo che non ci vorrà molto a fare questo passo
Se non sarà qualcuno/a degli iscritti a questa ml sicuramente sarà
qualche azienda che lo adotterà a forza di sentire il nostro
suggerimento ad adottarlo
Io in realta' ho gia' fatto qualcosa per migliorare la ricerca dei nomi
delle vie milanesi per il routing MilanoBiciMap.
Il sistema usa un algoritmo (si fa per dire) che prima estrae i nomi
dalle way di OSM e li salva in una tabella.
Quando va cercato un nome eseguo prima una query usando l'istruzione del
db match: select nome from nomi where match(nome) against('filtro')
Se viene trovata una corrispondenza la passo a nominatim.
L'algoritmo dell'istruzione match del db (mysql) funziona abbastanza
bene e con questo sistema vengono trovati molti piu' indirizzi che non
usando direttamente nominatim.
L'area che ho usato e' abbastanza limitata, bisognerebbe capire se
l'istruzione match scala bene quando la tabella contiene non solo i nomi
delle vie milanesi. Anche se non credo che tutti i nomi delle vie
italiane possano essere piu' di 10-20 volte piu' grandi di quella di Milano.
Il codice che ho usato consiste di 20 righe di php e di una procedura
xslt per estrarre i dati.
Se qualcuno vuole costruire un motore piu' organico posso passargli
quello che ho gia' fatto.
ciao
maxx
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Magliette OSM x ciclisti
Mi sa di no. -- View this message in context: http://gis.19327.n5.nabble.com/Magliette-OSM-x-ciclisti-tp5770368p5777104.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
[Talk-it] Strade asfaltate
Se una strada è asfaltata va indicato surface=asphalt o di default una strada è considerata asfaltata? -- View this message in context: http://gis.19327.n5.nabble.com/Strade-asfaltate-tp5777114.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] Strade asfaltate
2013/9/11 bredy bredy...@yahoo.it Se una strada è asfaltata va indicato surface=asphalt o di default una strada è considerata asfaltata? Non nuoce metterlo. Se una strada di default è asfaltata dipende dall'interpretazione e della regione nel mondo dove si trova e dalla classe. Per un'autostrada in Europa è pratticamente scontato, mentre una residential non è necessariamente asfaltata (però la maggiorparte lo sarà). Direi in Italia possiamo essere abbastanza sicuro che tutto sopra tertiary è asfaltato (quindi non troveremmo una secondary non asfaltata). Non c'è una risposta chiara purtroppo a quella domanda, decide il mappatore di metterlo o meno, ma non lo rimuoverei mai se qualcun'altro l'ha messo. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strade asfaltate
quindi è meglio metterlo se si sa che è asfaltata. -- View this message in context: http://gis.19327.n5.nabble.com/Strade-asfaltate-tp5777114p5777126.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
[Talk-it] Tromba delle scale su più livelli
Come si disegna la tromba delle scale su più livelli? Tipo quelle dei parcheggi. -- View this message in context: http://gis.19327.n5.nabble.com/Tromba-delle-scale-su-piu-livelli-tp5777172.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
[Talk-it] geojson.io
segnalo un nuovo progetto opensource di mapbox: https://github.com/mapbox/geojson.io che permette di avere in una interfaccia web un sistema di editing dedicato di file json, che ne permette anche l'importazione. istanza funzionante: http://geojson.io/#map=6/43.922/10.767 -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
