Re: [OSM-talk-be] Why I'm against a full automatic import (ook in het Nederlands) (Was CRAB Import Tool)
English only since I've slept minus 3 hours. Sorry. I can't help but aggree fully. In analogy, as we speak I'm trying to migrate data from a poi list of over 1000 poi's with my own version of this database using the customer foreign key to make this happen. (for an API) I'm actually pretty much against this action but there are few alternatives since it was poorly planned by the customer. I'm doing a full merge, so coordinates will come from mine, labels from the customer -They are actually bus stops-, public ones that are used by private transport in Antwerp, used by collective transporting services by BASF etc.). This is only 1000 poi's and it's a merger's hell. Arrival times differ between both version, even validity is offset. Sometimes important stuff has been put in a comment field. This makes me remember how hard it is to automate these things, I've done acts like that before, but here I am using an excell sheet(dump customer) and an sqlite database to construct this single table instead... I just cannot create an algorithm of my common sense on how to go about each record. The reason why I'm against such an action is because I cannot trust neither sources of the data to be consistent. You might manage to import 30%, even 60% without problem, but it will be like the 80/20 percent rule. 20% of the effort and time will be spent in importing 80% of the data, and vice versa, you'll spend 80% of your time on the remaining 20% of the data. You might also end up spending weeks using overpass to correct OSM before import. I've done a lot of those and I assure you, it's just crazy the kind of mistakes you find in OSM alone. addr:postcode=Zemst , addr:city=1980 first one that pops in my mind. I've done lots of corrections like that. But that is just one of many idiotic things, honest mistakes and ignorance at work, all well meant efforts, with the best intentions. So in the end, we'll need something like Ben proposed. It's a lot more fun indeed and it gives ownership, just perfect. Glenn On 2013-10-22 07:12, Marc Gemis wrote: Nederlands onderaan Allow me to explain why I'm against a full automatic import of the Crab data, as proposed on this mailing list I understand that this is the fastest way to get the data into OSM and ready for use by everybody. However, the data will then be owned by 1 or 2 people that did the import. They will not be able to cope with the consequences of the data they imported. The import software will have some flaws (double addresses, missing buildings, bad buildings, problems with associatedStreet merging, etc.) Will you clean up the mess that others made ? If, on the other hand, you allow people to import their own chunks of data (via the tool made by the French, a lot of people own the data. Every contributor takes some pride in the data s/he added and will be glad to make corrections to it. Even during the initial import improvements to the imported existing data will be made. The more people that do this, the better. It's all about community building. Build a community around this import. This community will do other things as well afterwards. You can hear the same message in all presentations on import at the SOTM US and SOTM conferences. Please take a look at those videos. - Nederlands--- Sta me toe om uit te leggen waarom ik tegen een volledige geautomatiseerde import van Crab data ben, zoals ergens voorgesteld werd. Ik begrijp dat sommigen de data snel in OSM willen krijgen, zodat het door iedereen kan gebruikt worden. Het gevolg daarvan is dat de gegevens door 1 of 2 mensen aangemaakt is. Zij kunnen niet alle probleempjes oplossen die ontstaan door deze invoer. Ik denk hierbij aan foutjes in de software die ervoor zorgen dat er dubbele adressen zijn of problemen met de associatedStreet-relaties. Ook wordt er tijdens de import ook niks gedaan aan ontbrekende of foutieve gebouwen. Wie gaat die problemen aanpakken die door anderen gemaakt zijn ? Als je aan de andere kant, iedereen toelaat om stukjes gegevens te importeren en onmiddellijk te verbeteren, krijg je een groep van mensen die de gegevens bezit/beheert. Deze mensen gaan in zekere zin fier zijn op hun werk en proberen de fouten eruit te halen. Hoe meer van deze mensen hoe beter. Het gaat dus over het opbouwen van een community. Bouw aub een community op rond deze import. Op langere termijn zal osm er wel bij varen. I meen deze boodschap ook te horen in alle presentaties rond imports die gegeven zijn op de SOTM US en SOTM conferenties. Kijk maar eens naar die videos. (wel in het Engels) groeten m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CRAB Import Tool
On Tue, Oct 22, 2013 at 05:36:28AM +0200, Marc Gemis wrote: So you are going to write an algorithm that matching addresses in OSM with addresses in Crab in order to add an id. Right now there are already addresses in OSM that are not in Crab. The same might happen next year. People might have added POIs with addresses. So you will always need an address based matching algorithm. So there is no reason to add the Crab id in OSM. I don't follow your reasoning here. Addresses in OSM but not CRAB shouldn't be a problem. I also don't understand your comment about POIs with an address. It's not because you can match a lot of the addresses based on al algorithm that you can find all of them. This *will* require people to manually fix things and manually add the relation between the 2. What do you mean by Fix our data ? Is Crab suddenly the holy grail ? I didn't say anything like that. I just say that our data *does* contain errors. I'm also pretty sure theirs contain errors. If we look at the differences we need to find out which one is correct, and then try to get the correct information in both. Their DB contains mistakes as well. I'm against a full automatic import. I'm still in favor of the workflow that Ben proposes. Using a website to download a street. Manually merging with existing data, drawing buildings, merging or splitting buildings were needed. Who wrote a few days back that house nodes without buildings are not so good (I'm not saying it was you) ? An automatic import cannot prevent that. I did say that I would prefer the address information is added to building, but that just having a housenumber and no building is better then nothing. I also don't see myself drawing all the buildings when I'm going to import the address information because it will take a lot more time. But I will at some point draw them. You might have different priorities than I. If I were to write an import tool, I would be careful on when to import something, and when in doubt don't import the address. I already have several rule in my head that could be useful. But it looks to me like nobody wants me to do this, so I'm not going to put any effort in this. It would be nice though to have something like Jo did for the busstops. Have a table for mismatches between the OSM data and the imported data. Such a list could be generated every year to see which data should be added or updated AGIV delivers updated files on daily basis. There should not be a problem to actually also compare them on daily basis, and update the list of nodes that still need to be imported on daily basis. But I don't see myself putting time in this if there is no relation between the 2 databases. Kurt ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CRAB Import Tool
FWIW I also see value in adding a backreference to CRAB in the OSM data. It will make it a lot easier to do automated follow up and comparison in the long run. I also see value in the slow but steady way of having contributors integrate the data. It's slower by an order of magnitude, but indeed community is more important than content in the long run. Jo 2013/10/22 Kurt Roeckx k...@roeckx.be On Tue, Oct 22, 2013 at 05:36:28AM +0200, Marc Gemis wrote: So you are going to write an algorithm that matching addresses in OSM with addresses in Crab in order to add an id. Right now there are already addresses in OSM that are not in Crab. The same might happen next year. People might have added POIs with addresses. So you will always need an address based matching algorithm. So there is no reason to add the Crab id in OSM. I don't follow your reasoning here. Addresses in OSM but not CRAB shouldn't be a problem. I also don't understand your comment about POIs with an address. It's not because you can match a lot of the addresses based on al algorithm that you can find all of them. This *will* require people to manually fix things and manually add the relation between the 2. What do you mean by Fix our data ? Is Crab suddenly the holy grail ? I didn't say anything like that. I just say that our data *does* contain errors. I'm also pretty sure theirs contain errors. If we look at the differences we need to find out which one is correct, and then try to get the correct information in both. Their DB contains mistakes as well. I'm against a full automatic import. I'm still in favor of the workflow that Ben proposes. Using a website to download a street. Manually merging with existing data, drawing buildings, merging or splitting buildings were needed. Who wrote a few days back that house nodes without buildings are not so good (I'm not saying it was you) ? An automatic import cannot prevent that. I did say that I would prefer the address information is added to building, but that just having a housenumber and no building is better then nothing. I also don't see myself drawing all the buildings when I'm going to import the address information because it will take a lot more time. But I will at some point draw them. You might have different priorities than I. If I were to write an import tool, I would be careful on when to import something, and when in doubt don't import the address. I already have several rule in my head that could be useful. But it looks to me like nobody wants me to do this, so I'm not going to put any effort in this. It would be nice though to have something like Jo did for the busstops. Have a table for mismatches between the OSM data and the imported data. Such a list could be generated every year to see which data should be added or updated AGIV delivers updated files on daily basis. There should not be a problem to actually also compare them on daily basis, and update the list of nodes that still need to be imported on daily basis. But I don't see myself putting time in this if there is no relation between the 2 databases. Kurt ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] Wiki Mapia Mass Upload
Thanks. I have now written to their contact email address asking them to comply with our license or remove the data. I will report back on what transpires. Mike Michael Collinson License Working Group On 15/09/2013 16:54, Walter Nordmann wrote: got some: New from 18. August 2013: http://wikimapia.org/28575157/de/Hummelsbütteler-Kirchenweg-15 http://www.openstreetmap.org/browse/way/171350548/history And another new one with an error at the upper right corner http://www.openstreetmap.org/browse/node/2423349643 from the german forum: http://forum.openstreetmap.org/viewtopic.php?pid=362179#p362179 Regards walter - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0.2[/url] -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Wiki-Mapia-Mass-Upload-tp5777641p5777659.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] License / Copyright - OSM data for commercial use artistic map
OpenLayers is very distinct from any map layers. OpenLayers is a piece of software, a map layer is generally a set of images. I don’t see OpenLayers in use on the site you linked at all. Assuming the Papercraft map linked there is using recent ODbL data, there needs to be an attribution statement on the paper, and if they’re adding data to their local copy of the OSM dataset before rendering, they’d need to license that under the ODbL. As a practical matter, I highly doubt anyone would add data to their local copy for a low-zoom map of Stockholm. This doesn’t mean that they have to release the software they’re using to render the map, to display it in such a weird way, or to release their cartography. From: Beri Dániel [mailto:daniel.b...@evk.hu] Sent: Monday, October 21, 2013 3:25 AM To: Jonathan Harley Cc: legal-talk@openstreetmap.org Subject: Re: [OSM-legal-talk] License / Copyright - OSM data for commercial use artistic map Hi Jonathan! Thank you very much for clearing things up, and explaining the difference between the treatment of data sets and other things I would put on the map. The treatment of OSM data, and the alteration of it is fine, understood, and obviuosly I can live with it. Although, the licensing/copyright of the layer which I would ask my programmer to define in OpenLayers and which then would be filled with images is still a bit fuzzy. Aren't these two statements opposite to each other: 1. OpenLayers uses the FreeBSD license which places no limitations on use other than that you must distribute it with its license intact. 2. you can retain all rights on your other data, images and published maps What would Point1 include in itself? Maybe I misunderstood the whole concept of the word layer. I thought that the visual outlook of the map what makes it a map, what people see (and in may case consists of the collection of images put together) is on a layer and hence should be distributed accordingly? This would imply that I could I ask the author of this projec http://nordpil.com/go/products/stockholm-papercraft/ t to distribute the layer he defined? (Obviously I don't want to, as I cheer for Point2 to be true in case of my project as well :) Thanks in advance again! Daniel On 21 October 2013 11:25, Jonathan Harley j...@spiffymap.net wrote: On 19/10/13 11:11, Beri Dániel wrote: Dear All, I would like you to have a look at my question I posted in the OSM forum yesterday. It is not an urgent matter, I'm duplicating it here as well because I would like to avoid any mistreatment of the OSM licenses. Below you can read my post from the forum, or just simply have a look at it in the forum itself: http://forum.openstreetmap.org/viewtopic.php?id=22948 Thanks in advance! Daniel Hi Dániel, overall your project does sound like what's presented to users would be a produced work and there is no problem with commercial use. AFAIK OpenLayers uses the FreeBSD license which places no limitations on use other than that you must distribute it with its license intact. The only part which would constitute a derivative database is your altered OSM data (point 2). This altered data will clearly be derived from OSM's data and you would need to publish this under ODbL. If you store the data about where your users live (point 5) in a database, and if this data is derived from the OSM map (users drop a pin on your map based on what they see on it, or where the OSM-based search server said they are), then this is also a derivative database and must also be made available under ODbL. Note that a database here just means a data set - the set of data that was derived from OSM. The ODbL license does not extend virally to any other data sets you may happen to store in the same database management system. The derived data is the only thing you must distribute freely (if asked to), and you can retain all rights on your other data, images and published maps. HTH - Jonathan Dear All, This might have been discussed several times, hence sorry for raising this question again, but I really would like to make sure that I'm in compliance with the rules of the OSM license. (Also, I'm not a programmer, so, sorry for formulating the details of my envisaged project with lack/inproper use of the programming jargon.) So, here is the list of things I am planning to do: I would like to create an artistic map 1) *based on OSM data* - I would need a world map, with territories of countries and potentially subdivisions as well 2) *I would alter the OSM data* by defining new, custom subdivisions in certain areas, like cutting half a country (or continent, like Antarctica) not along any currently available line, but according to my wish 3) I would like to *put copyrighted images* onto these subdivisions (with OpenLayers) 4) I would *remove uneccessary detail by not rendering some types of features*, ie. I don't want any other data to
[OSM-talk] planet-131017.osm.pbf
Hi. Does anybody know why planet-131017.osm.pbf doesn't have md5 sum and only 19G vs usual 22G I check it by thous links: http://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/pbf/ ftp://ftp.spline.de/pub/openstreetmap/pbf/ Is pbf for thous date was broken? -- Best regards dmitry.v.kise...@gmail.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
2013/10/22 Bryce Nesbitt bry...@obviously.com On Mon, Oct 21, 2013 at 2:11 PM, Johan C osm...@gmail.com wrote: Essentially what we need is the concept of layers. I don't think we really need layers, but could use editors that are semantically aware of things like boundaries, and put them in the background until needed. As far as I see, if we just prevent certain ways or nodes to share nodes with others, that is as good as a layer. So if we say boundary=* can only share nodes with each other, then that is a layer. I think those rules are better then inventing some arbitrary fixed layers. Janko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
Janko Mihelić wrote: I don't think we really need layers, but could use editors that are semantically aware of things like boundaries, and put them in the background until needed. As far as I see, if we just prevent certain ways or nodes to share nodes with others, that is as good as a layer. So if we say boundary=* can only share nodes with each other, then that is a layer. I think those rules are better then inventing some arbitrary fixed layers. I think that this is part of the 'problem' Sharing nodes was thought to be a good idea, but that only works well when all of the data is tightly related. Once one introduces 'loosly' related data, then there is a need for separating nodes depending on their 'layer'. I feel we are getting to the point where we need to think about 'sharing' ways rather than jst sharing nodes. Returning to the example of field boundaries, an existing 'way' that forms the edge between two other areas only needs to exist once, so drawing the next field can be done using the existing boundaries, and many areas simply become relations picking up a list of ways. Moving to the higher levels, boundaries of the smaller elements get used in a lest of ways bounding the bigger one. These shared ways would have their own set of nodes which may relate to underlying ways ... rivers for example ... but would not neceserally be the same way. Information would be managed in 'layers' but these may well be tagged by time rather than 'level' and just allow an easier way to filter what is being used? Currently what we are doing with areas when used for objects like land use IS wrong? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
On Sat, Oct 19, 2013 at 11:16 PM, Colin Smale colin.sm...@xs4all.nl wrote: I think it might be easier to define a new boundary/multipolygon relation per time zone, containing all the boundary ways, in inner and outer roles as usual. Or create a relation collecting all boundaries/multipolygons relations (and only relations) being in the same timezone. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
2013/10/22 Janko Mihelić jan...@gmail.com I don't think we really need layers, but could use editors that are semantically aware of things like boundaries, and put them in the background until needed. As far as I see, if we just prevent certain ways or nodes to share nodes with others, that is as good as a layer. So if we say boundary=* can only share nodes with each other, then that is a layer. I think those rules are better then inventing some arbitrary fixed layers. It really depends on the legal situation, sometimes sharing nodes is the right thing to do (if the boundary is defined as being the river for instance), sometimes it is to be seen distinctly (when the boundary is defined by independent coordinates). In other cases it is even worse as there are several official versions for the same boundary ;-) (in the case of disputed boundaries, there are more cases than you might think). cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
On Tue, Oct 22, 2013 at 7:11 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: It really depends on the legal situation, sometimes sharing nodes is the right thing to do (if the boundary is defined as being the river for instance), sometimes it is to be seen distinctly (when the boundary is defined by independent coordinates). In other cases it is even worse as there are several official versions for the same boundary ;-) (in the case of disputed boundaries, there are more cases than you might think). Just because the boundary is defined being the road, doesn't mean the nodes should be shared. The boundary may be aligned with a river or road, but not necessarily connected. Connecting a boundary or landuse to a road or river serves no useful purpose other than making it easy to add. But difficult to change later. I would be very happy if the editor complained if a mapper tried to connect roads/rivers and boundaries and landuse areas. As was pointed out, borders may originally be defined as a river or road, but once defined the river and road can easily change while the border remains the same. For example here is an excerpt from Wikipedia: In March 1876, the Mississippi suddenly changed course near the settlement of Reverie, Tennessee http://en.wikipedia.org/wiki/Reverie,_Tennessee, leaving a small part of Tipton County, Tennesseehttp://en.wikipedia.org/wiki/Tipton_County,_Tennessee, attached to Arkansas http://en.wikipedia.org/wiki/Arkansas and separated from the rest of Tennessee http://en.wikipedia.org/wiki/Tennessee by the new river channel. Since this event was an avulsionhttp://en.wikipedia.org/wiki/Avulsion_(river), rather than the effect of incremental erosion and deposition, the state line remains located in the old channel.[24]http://en.wikipedia.org/wiki/Mississippi_River#cite_note-Arkansas_v._Tennessee.2C_246_U.S._158-24 When boundaries are tied to roads or rivers, a mapper could move both even though only the road or river changed. -- Clifford OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
I guess I see admin boundaries as something typically shown on rendered maps so it makes sense having them in there to me. To be honest I don't have a particularly strong view about time zones per se, but just expressing caution at getting into a theoretical situation where the database is so cluttered with all manner of stuff that those of us that just want to work with map data have a harder time extracting the data we want. Nick -Colin Smale colin.sm...@xs4all.nl wrote: - To: talk@openstreetmap.org From: Colin Smale colin.sm...@xs4all.nl Date: 21/10/2013 10:25AM Subject: Re: [OSM-talk] Timezones (was: Deleting data) Nick, this can be done for admin boundaries as well. Would you advocate removing them from OSM as well? The change to the size of the planet file if timezones are included is absolutely microscopic in the big scheme of things. There are clearly many shades of grey. It's a question of where to draw the line (as it were). Can this be expressed objectively? It feels rather weird that some people are now advocating keeping certain things out of OSM. The traditional consensus is that anyone can put anything in OSM and that any attempt to limit people's creativity is met with much scepticism. In the continuum between the puritans and the pragmatists there's plenty of room for everyone. I for one think that data in OSM should be above all usable. Whether to have timezones in OSM is analogous to database normalisation. If taken to extremes, you can win a theoretical point while at the same time causing significant performance problems and extra complexity for the users of the data. Colin On 2013-10-21 10:55, Nick Whitelegg wrote: I'd go the other way and abolish Winter Time. ;-) No DST = dark summer evenings. Not nice! Going on topic, not sure if something like time zones belongs in OSM. Would it not be better to use a more specialised web service to look up time zones for a given lat/lon? I'd prefer to minimise overloading OSM with things which are not on the ground data. For one thing, it means bigger planet files and more demands on software to extract the data you want. Nick -moltonel 3x Combo molto...@gmail.com wrote: - Actually, I always wondered why timezones were kept out of OSM. I know DST complicates tagging (it'll be the first thing I abolish when I become World Dictator), ... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Mapping of multiple-lane toll areas
I came across this gem: http://www.openstreetmap.org/#map=18/45.34907/9.31020 Is this really how we want to map toll areas? A seperate way for each lane? (forget the fact that half of them aren't even connected). I can imagine having seperate lanes for seperate payment methods, but IMHO this is just silly. Regards, Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping of multiple-lane toll areas
It is silly. Maybe too few mappers use the Wiki. Surely this mapper didn't. http://wiki.openstreetmap.org/wiki/Lane_assist 2013/10/22 Maarten Deen md...@xs4all.nl I came across this gem: http://www.openstreetmap.org/**#map=18/45.34907/9.31020http://www.openstreetmap.org/#map=18/45.34907/9.31020 Is this really how we want to map toll areas? A seperate way for each lane? (forget the fact that half of them aren't even connected). I can imagine having seperate lanes for seperate payment methods, but IMHO this is just silly. Regards, Maarten __**_ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.**org/listinfo/talkhttps://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping of multiple-lane toll areas
On 22/10/2013 22:13, Johan C wrote: It is silly. Maybe too few mappers use the Wiki. Surely this mapper didn't. http://wiki.openstreetmap.org/wiki/Lane_assist Ignoring that they're not joined, I'm not sure what's wrong with this. Complicated detailed, yes, but not incorrect. Lane assist tagging isn't relevant here as that's to indicate lanes to different destinations. Here there's only one destination for each direction. Also it would be more confusing as the lanes split join in different locations. In theory the Individual lanes tolls could be used by the operator to indicate which booths are open what vehicles you can take through them (many have HGV only booths). One thing I think is incorrect is the 130k speed limit. It's a bit hard to throw your euros into the bucket at that speed. Cheers Dave F. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping of multiple-lane toll areas
On Tue, Oct 22, 2013 at 5:32 PM, Dave F. dave...@madasafish.com wrote: Lane assist tagging isn't relevant here as that's to indicate lanes to different destinations. Here there's only one destination for each direction. Also it would be more confusing as the lanes split join in different locations. In theory the Individual lanes tolls could be used by the operator to indicate which booths are open what vehicles you can take through them (many have HGV only booths). I split the ways where medians are present and do my best to tag access, maxspeed, maxwidth, maxheight as known. Would be handy if more routers had an idea what payment you intend to use, since Pikepass users pay like an old ATT commercial at speeds between 30 and 75 MPH (depending on age of the plaza, ones built in my lifetime are full-speed-ahead for pikepass users) at most plazas. Cimarron Turnpike could very well be the only exception in the OTA system, thanks to horseshoe ramps for exits at toll plazas, forcing Pikepass users to wait in line in the Cash/Check/Tourist Information line when entering and exiting. PS, if you use that lane when there's a line at the toll plaza and start playing 20 questions for tourist information...I hate you. Go play 20 Questions at the concessions plaza where you're out of the way... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] Openstreetmap Quality Issues
http://www.gazette.vic.gov.au/gazette/Gazettes2013/GG2013S204.pdf Not sure what all this is about but may be of interest (it does mention Diggers Way). ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Vandalism in Sydney OSM data ?
Hello Aussie mappers By chance I found the following problem: It seems that there happened some vandalism (or someone who did some very unhappy changes) in Sydney. Long parts of Sussex Street disappeared, as well as the Cross City Tunnel. Maybe there is someone who has better knowledge than me in searching for the lost information and reverting it. Thx Creando from germany, visiting Australia from next week on :-) ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[Talk-de] Voting für power line refinement
Hi, hier läuft noch die Abstimmung zum power line refinement: http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO-Ersatz für Garmin?
Sven Geggus li...@fuchsschwanzdomain.de wrote: Johannes Formann johan...@formann.de wrote: Eine gemeinsame Plattform hätte für mich auch viele Vorteile, bräuchte deutlich weniger RAM und Traffik für meinen Server, nur wer soll die Infrastruktur betreiben? Na ja, den FOSSGIS Server gibt es ja schon. Nicht die schnellste Kiste aber immerhin. Wenn ich das richtig sehe laufen dort derzeit die AIO und die Karte von Computerteddy. Allerdings _ohne_ nennenswerte Synnergieeffekte :( Nur ob das Skaliert? Grob überschlagen stehen alleine im Wiki über 50 Karten, wenn man die alle wöchentlich weltweit generieren wollen würde, dann bräuchte man schon einen kleinen Cluster nur von der Rechenzeit. Von so wünschenswerten Angeboten wie frei vom Benutzer wählbare Bereiche (Würde ich zugegebenermaßen gerne anbieten, aber dafür fehlt mir die Toolchain) ganz abgesehen. Und der resultierende Traffik wäre vermutlich auch nicht zu unterschätzen. Meine im Vergleich mit der OpenCycleMap und OpenMTBmap recht unbekannte Radkarte macht auch noch im Sommer etwa 1,5TB pro Monat. Und das in der Niesche Karten fürs Radfahren. Grüße Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO-Ersatz für Garmin?
Johannes Formann johan...@formann.de wrote: Und der resultierende Traffik wäre vermutlich auch nicht zu unterschätzen. Das kann man über Spiegel wie z.B. bei der gwdg abfedern. Macht download.geofabrik.de ja auch so. Sven -- Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open Source-Betriebssystem bedenken sollten, ist, dass Sie kein Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu) /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] AIO-Ersatz für Garmin?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.10.2013 11:02, schrieb Sven Geggus: Allerdings _ohne_ nennenswerte Synnergieeffekte :( Darüber hatte ich mal mit Computerteddy gesprochen. Synergien wären schon möglich. Bspw. die Verwendung eines planet, aus dem sich alle direkt mit dem Splitter ihre Daten ziehen. Wenn die Input-Daten identisch sind, wäre sogar beim Splitten noch mehr Synergie möglich. Das war bei unseren beiden Karten (Computerteddy und RadReiseKarte) leider nicht der Fall, da die RadReiseKarte bspw. auch SRTM-Daten benötigt. Bei gleichem Input kann Splitter auf einem aktuellen Desktop ohne Probleme 4000 Kacheln in einem Durchlauf schneiden. Beim eigentlichen Rendern mit mkgmap ist es dann vorbei mit der Synergie. Beim Splitten kann auch noch recht viel Zeit gespart werden, wenn man eine statische areas.list verwendet und diese aktualisiert, wenn mkgmap meckert. Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSZqfUAAoJEPFgsWC7jOeTeaQIAJVWX3iUx/5t/V3e0yFBfYZR LhJFDpZpHtj0XbTc2Y61G5XZsO4d18AsZQZtf1Gw9nGTjNSHmqMXl+MtiPNsdXKA xlzFzIndxtdx1+0twwqvnfQrEJfl5+7h85h6/AYgC/W/eBdA2e2f4+Lk3ym9sf3o BMTfZaxKw6aewctFPjWybuTiI9MDW1OZWRTr9MQ4ZBTK3AY9nzdKPL8/EZ7fjjHs g0niz6pdQhmGVrPZSct/MzCIRQfpT6vju+ARhKlR74VLpsRvpNnM9N3+XRMXYSXY LATjn/4wegIQ/w98EmW1Q/kzE8AZe2oFxn2lh8GDE6O7vj9vthxZLYzO0XQehOE= =Fze0 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] craft=beekeeper und Direktverkauf
Hallo, 2013/10/21 Jörg Frings-Fürst o...@jff-webhosting.net zuerst einmal ich lehne das taggen nicht ab, [...] schön! ich bin nur der Meinung das das in den besprochenen Fällen nicht sinnvoll ist. Überlege einmal: der Stand wurde gemappt. Der Betreiber geht in Urlaub, Stand wird abgebaut -- nächster Mapper löscht den Stand wieder in OSM. Zum zweiten sehe ich ein Problem mit der Wartung bzw. den ständig aktuell zu haltenen Aktivzeiten. Du wirst in einigen Fällen recht haben. Dort wo aber das Schild und/oder der Stand ständig bleibt, akzeptiere ich deine zwei obigen Argumente nicht. Und für hier in dem Fall der Imker, was ja IMHO dem Verkauf von Honig impliziert, sollte der Imker - Tag reichen. [...] Und es ist IMHO eine gewagte Annahme, dass jeder Imker Honig zum Verkauf anbietet. Vielleicht vermietet er Bienen an Bauern oder er bietet weder Produkte noch Dienstleistungen an. Laut[1] gibt es allein in Deutschland ca. 94.000 Imker. Bei OSM[2] sind mal gerade 215 weltweit eingetragen. Warum gibt es wohl so wenige Eintragungen? Weil kein vernünftiges Tagging-Schema dafür existiert! Verwandt ist nur shop=farm. Was ist wohl - wenn es sein muss (-; - besser? 1) shop=farm + building=no [1] + produce=honey + produced_on_site=yes [2] Mein Bedenken: Honig ist kein Produkt vom einem farm, außerdem impliziert shop=farm für mich eine größere Auswahl als 1-2 Produkte 2) shop=stall [3] + produce=honey + produced_on_site=yes Viele Grüße, Nils [1] shop=farm + building=no wurde von fly in diesem Thread für einen Verkauftstand mit landwirtschaftlichen Produkten vorgeschlagen [2] produced_on_site=yes/only/most/some/few/no habe ich hier gefunden: http://wiki.openstreetmap.org/wiki/Proposal/Shop%3Dbakery,confectionery [3] Etwa die Bedeutung von market stall: http://en.wikipedia.org/wiki/Market_stall ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] [OT] agenda digitale Emilia Romagna
Il giorno 22 ottobre 2013 07:54, Maurizio Napolitano napoo...@gmail.comha scritto: Vi scrivo per informarvi che faro' parte del comitato scientifico delle scelte dell'agenda digitale dell'Emilia Romagna Complimenti! Sono stato chiamato in virtu' del mio lavoro ma non sara' per me occasione di spingere su diverse tematiche di valorizzazione della condivisione dei saperi (ergo open source, open data, openstreetmap, wikipedia...) Qui c'e' un NON di troppo. Forse sara' occasione di spingere... Saluti Fabrizio ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] agenda digitale Emilia Romagna
Sono stato chiamato in virtu' del mio lavoro ma non sara' per me occasione di spingere su diverse tematiche di valorizzazione della condivisione dei saperi (ergo open source, open data, openstreetmap, wikipedia...) Qui c'e' un NON di troppo. Forse sara' occasione di spingere... inizio bene :) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Way tra scalinate
Tenete presente che e' una prima mappatura, andra' poi verificata sul campo. Vada per footway o pedestrian. Riguardo ai temerari, nelle foto su Bing c'e' gente che sale le scalinate con la propria auto per parcheggiare... highway=steps foot=designated car=temerary car:oil_cup=bye_bye Grazie a tutti. Saluti Fabrizio Il giorno 21 ottobre 2013 23:06, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: Am 21/ott/2013 um 18:30 schrieb Fabrizio Tambussa ftambu...@gmail.com: Come classifico questa porzione di 100 metri di via? Io penserei a pedestrian, visto che non posso ragionevolmente salire/scendere le scale con la moto o con la bici. Faccio bene? se si accede solo tramite scale metto anch'io footway o quando è veramente largo pedestrian. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] agenda digitale Emilia Romagna
Buon lavoro. Ciao /niubii/ Il 22/ott/2013 08:15 Maurizio Napolitano napoo...@gmail.com ha scritto: Sono stato chiamato in virtu' del mio lavoro ma non sara' per me occasione di spingere su diverse tematiche di valorizzazione della condivisione dei saperi (ergo open source, open data, openstreetmap, wikipedia...) Qui c'e' un NON di troppo. Forse sara' occasione di spingere... inizio bene :) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [OT] agenda digitale Emilia Romagna
Complimenti Maurizio e buon lavoro!!! Cesare Gerbino http://cesaregerbino.wordpress.com/ http://www.facebook.com/cesare.gerbino http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl https://twitter.com/CesareGerbino http://www.linkedin.com/pub/cesare-gerbino/56/494/77b Il giorno 22 ottobre 2013 07:54, Maurizio Napolitano napoo...@gmail.comha scritto: Vi scrivo per informarvi che faro' parte del comitato scientifico delle scelte dell'agenda digitale dell'Emilia Romagna http://salastampa.regione.emilia-romagna.it/comunicato.jsp?codComunicato=45240 Sono stato chiamato in virtu' del mio lavoro ma non sara' per me occasione di spingere su diverse tematiche di valorizzazione della condivisione dei saperi (ergo open source, open data, openstreetmap, wikipedia...) Non so quanto riusciro' ad essere incisivo, ma spero di portare feedback da questa ed altre comunita'. Quindi, se siete da quelle parti spero di aver modo di collaborare Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Way tra scalinate
Am 22/ott/2013 um 08:16 schrieb Fabrizio Tambussa ftambu...@gmail.com: Riguardo ai temerari, nelle foto su Bing c'e' gente che sale le scalinate con la propria auto per parcheggiare... highway=steps foot=designated car=temerary car:oil_cup=bye_bye si, conosco situazioni simili nel Lazio, ho aggiunto il tag flat_steps=yes dove i gradini erano significativamente meno ripidi di 17/30 (alzata/pedata) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Richiesta per datalogger
Innanzitutto Grazie Ho trovato il gps consigliatomi (garmin) a 178 €. È veramnte un bel articolo. Il bagget a disposizione non si avvicina all'offerta. Mi è sufficiente un datalogger anche senza mappe e bussola ma con una buona ricezione/precisione (dimensioni minori, senza schermo) tipo il 747A+ potrebbe andare. Immagino che trovare un data loggher a doppia frequenza (L1 - L2) sia un po' azzardato o quanto meno richiederebbe una spesa enorme? Grazie di nuovo per l'attenzione se avete altri suggerimenti, aspetto in linea :-) Grazie Nicola - Usa software libero -- View this message in context: http://gis.19327.n5.nabble.com/Richiesta-per-datalogger-tp5782370p5782463.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] Way tra scalinate
Non conosco il caso specifico, ma spesso nei gradini è ricavata una vera e propria rampa in pietra o in cemento per consentire il passaggio delle ruote di carretti o autovetture. Ciao /niubii/ Il giorno 22 ottobre 2013 09:32, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: Am 22/ott/2013 um 08:16 schrieb Fabrizio Tambussa ftambu...@gmail.com: Riguardo ai temerari, nelle foto su Bing c'e' gente che sale le scalinate con la propria auto per parcheggiare... highway=steps foot=designated car=temerary car:oil_cup=bye_bye si, conosco situazioni simili nel Lazio, ho aggiunto il tag flat_steps=yes dove i gradini erano significativamente meno ripidi di 17/30 (alzata/pedata) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Standardizzazione toponimi bilingui della Sardegna ed adattamento al modello altoadesino
ciao, qui un pezzo dove sparo a zero sull'iniziativa google in sardo. http://sardiniaopendata.org/2013/10/22/bilinguismo-web-e-nuove-tecnologie-ce-molto-da-lavorare/ cmq sia ci ho pensato sui nomi ufficiali bilingui, la cosa che mi preoccupa è che renderanno più difficile il riutilizzo dei dati osm per altri scopi. Tipo l'estrazione di informazioni sui comuni o il routing. deh. Il 19/10/2013 01:13, Luca Meloni ha scritto:marco Ciao a tutti, a quanto pare ci sono anche alcuni pareri contrari (anche se il problema della Babele non credo si ponga. I casi con più di due nomi sono rarissimi, in Sardegna poi le varie lingue sono ufficiali ed utilizzate in aree separate, motivo per cui ad esempio ad Alghero andrebbe messo il nome in catalano ma non in sardo, e anche basandosi sui cartelli stradali lì si trovano solo in catalano). Per adesso siamo 8 a favore, 4 contrari e alcuni indecisi/non l'hanno detto. Come ho scritto prima, nella quasi totalità dei comuni sardi è stata approvata a livello comunale la forma ufficiale, dato che uno standard assoluto non esiste (la LSC è ancora in fase sperimentale). Negli altri casi credo anch'io che vada inserito il nome locale (infatti di solito è questo a venire approvato). Comunque in generale su wikipedia si trova per primo il nome ufficiale (se ce ne sono diversi). Poi certo, gli altri possono essere comunque messi come alt_name. In generale sono d'accordo con quello che ha scritto Paolo. Idem per la sbarra. Per quanto riguarda gli altri discorsi (tileservers, renders etc.) mi astengo in quanto so a malapena di cosa state parlando. L'unica cosa che posso dire è che per la mappa su toolserver c'è il problema di non avere a disposizione tutte le opzioni e l'interfaccia della mappa generale. Ma quindi posso mettermi ad inserire le nuove informazioni? A favore: /Luca Meloni //sabas88 //Martin Koppenhoefer //andria_osm //Damjan Gerl/ /Paolo Monegato/ /Volker Schmidt/ /Elena ``of Valhalla'' / Contrari: //Stefano Salvador ///Francesco Pelullo //Andrea Musuruane //Tiziano D'Angelo/ Non lo so: /Davio //Luca Delucchi/ /Alexander Roalter //Pietro/ Il Venerdì 18 Ottobre 2013 19:57, Paolo Monegato gato.selvad...@gmail.com ha scritto: Il 18/10/2013 10:51, Stefano Salvador ha scritto: Provocazione: perché in Friuli e Sardegna si e in Veneto e Lombardia no Perché c'è la serie A e la serie B o meglio: la serie A1 (tedesco, francese, sloveno), la serie A2 (altre della 482/99) e la serie B (quelle rimaste fuori)... perché nel mio paesello in Friuli devo usare il friulano standard e non quello con cui tutti gli abitanti chiamano il paese ? Perché lo standard è in A2, l'altro in B... Il 18/10/2013 11:48, Stefano Salvador ha scritto: Visto che il problema è così sentito potremmo iniziare una raccolta fondi per metterlo in piedi. Alcune regioni finanziano progetti di tutela degli idiomi locali, magari si potrebbe fare un tentativo... Il 18/10/2013 11:50, Martin Koppenhoefer ha scritto: 2013/10/18 Paolo Monegato gato.selvad...@gmail.com mailto:gato.selvad...@gmail.com I nomi andrebbero inseriti su OSM lo stesso anche se privi del crisma dell'ufficialità. Ovviamente se ufficiali vanno in name, altrimenti in name:lingua. non è ne anche così chiaro, perché alle volte mettiamo i nomi ufficiali in official_name e la forma più comune in name (vedi Italia vs. Repubblica Italiana) Si, ma con ufficiali non intendevo il nome ufficiale completo ma se la forma comune è ufficializzata (tipo nello statuto comunale) o no. Il 18/10/2013 12:23, Elena ``of Valhalla'' ha scritto: +1: sul name:lang è buono e giusto inserire più nomi possibile (al limite può esserci il problema di che varietà usare quando ci sono differenze nella stessa lingua, ma quello va risolto di caso in caso da chi è del posto). Mi sembra un problema facilmente risolvibile: Se c'è uno standard in name:lingua va quello e le differenze locali vanno in loc_name:lingua (sottolineo l'importanza di specificare la lingua anche per i loc_name). Se non c'è uno standard va il nome locale (con eventuale alt_name:lingua). Esempio pratico: - Casarsa della Delizia (PN), essendoci il friulano standard: name:fur=Cjasarse, loc_name:fur=Cjasarsa - Belluno, non c'è un veneto standard: name:vec=Belun, alt_name:vec=Beƚun Se poi il problema fosse la grafia IMHO andrebbe valutato caso per caso. Ove possibile sarebbe meglio scriverli tutti con la medesima grafia ed eventualmente aggiungere altre forme grafiche con un altro tag (es name:vec e name:vec_clas o name:vec_trad)... I cartelli stradali sarebbero un criterio pratico da rilevare, ma purtroppo non sono affidabili: spesso vengono cambiati in modo arbitrario al cambiare delle amministrazioni, per di pi`u anche in modo contrario al codice della strada (vedi cartelli bianchi / marroni) e talvolta sono persino in contraddizione tra loro, quando non tutti i cartelli son stati cambiati. Vero. ciao Paolo M ___ Talk-it
[Talk-it] Contattare i mapper di una regione
E possibile inviare una mail o un messaggio a tutti quelli che partecipano nella mappatura di una regione? Se si come? -- View this message in context: http://gis.19327.n5.nabble.com/Contattare-i-mapper-di-una-regione-tp5782471.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] Way tra scalinate
2013/10/22 Francesco Pelullo f.pelu...@gmail.com Non conosco il caso specifico, ma spesso nei gradini è ricavata una vera e propria rampa in pietra o in cemento per consentire il passaggio delle ruote di carretti o autovetture. si, però nel caso specifico non c'era proprio rampa, era una piazza con solo gradini e le macchine passavano / parcheggiavano (era accessibile solo ai autorizzati credo)... Tipo qui: http://binged.it/1fSTyV9 Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Richiesta per datalogger
Anche a me incuriosisce un dispositivo con cui registrare tracce GPS con precisione. Attualmente uso il GPS integrato in uno smartphone, ma mi domando se gli strumenti dedicati abbiano una precisione maggiore. Grazie! ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Elettrauto
Come si mappa? Ho trovato shop=car_repair, ma come specificare che è un elettrauto e non, per esempio, un meccanico? Nella documentazione italiana [1] si propone: shop=car service=electrical Ma, anzitutto, shop=car presuppone che il negozio principalmente *venda* auto e faccia manutenzione come attività secondaria [2]. Inoltre, service=electrical significherebbe che vengono riparate auto elettriche [2]. Un elettrauto tipicamente lavora su auto con motore a scoppio, invece. -- [1] https://wiki.openstreetmap.org/wiki/IT:Tag:shop%3Dcar [2] https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Elettrauto
Il giorno 22 ottobre 2013 16:43, solitone solit...@mail.com ha scritto: Come si mappa? Ho trovato shop=car_repair, ma come specificare che è un elettrauto e non, per esempio, un meccanico? Nella documentazione italiana [1] si propone: shop=car service=electrical Ma, anzitutto, shop=car presuppone che il negozio principalmente *venda* auto e faccia manutenzione come attività secondaria [2]. Inoltre, service=electrical significherebbe che vengono riparate auto elettriche [2]. Un elettrauto tipicamente lavora su auto con motore a scoppio, invece. Mi trovi parzialmente d'accordo. Trovo anch'io più corretto usare car_repair invece che car. Invece service=electrical mi sembra adatto. Non si confonde electrical (attività legata all'elettricità e ai componenti elettrici) con electric car. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Contattare i mapper di una regione
On Tue, Oct 22, 2013 at 11:26 AM, bredy bredy...@yahoo.it wrote: E possibile inviare una mail o un messaggio a tutti quelli che partecipano nella mappatura di una regione? Se si come? questa mappa dovrebbe fare al caso tuo, ma sembra che non funzioni in questo momento: http://resultmaps.neis-one.org/oooc?zoom=14lat=40.66847lon=16.5997layers=00BTFT -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Contattare i mapper di una regione
Si c'è anche la mappa dei contributors che funziona, ma bisogna selezionare uno ad uno gli utenti cosa impensabile visto il numero. Da: Simone Cortesi sim...@cortesi.com A: openstreetmap list - italiano talk-it@openstreetmap.org Inviato: Martedì 22 Ottobre 2013 16:58 Oggetto: Re: [Talk-it] Contattare i mapper di una regione On Tue, Oct 22, 2013 at 11:26 AM, bredy bredy...@yahoo.it wrote: E possibile inviare una mail o un messaggio a tutti quelli che partecipano nella mappatura di una regione? Se si come? questa mappa dovrebbe fare al caso tuo, ma sembra che non funzioni in questo momento: http://resultmaps.neis-one.org/oooc?zoom=14lat=40.66847lon=16.5997layers=00BTFT -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Elettrauto
Simone Saviolo ha scritto: Invece service=electrical mi sembra adatto. Non si confonde electrical (attività legata all'elettricità e ai componenti elettrici) con electric car. Ok, lo penso anch'io. La confusione mi era nata leggendo la descrizione data sul wiki che ho citato prima. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] OpenStreetMap sulla tv di Matera
http://www.youtube.com/watch?v=ZEER4FFU_sE PS: sbiribizio e' diventato una leggenda per Matera a causa dei suoi interventi sulla mappa. -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-lt] Dviračių infrastruktūros žymėjimas Lietuvoje
Sveiki! čia keleta nesamonių: * Lietuviu kalboje yra tris savokos: takai, trasos ir marsrutai. Angliskai nera toks ryskus skirtumas tarp trasos ir marsrutu Takai yra pastatyti ir izenklinti, trasos yra irengti o marsrutas gali buti bet koks nubreziamas ant zemelapio. Tai pavadinti marsrutus rekreaciniais takais man yra visiskai be prasmes ... As pabandziau akcentuoti, kad takai yra SUSISIEKIMO infrastruktura ir trasos yra LAISVALAIKIO infrastruktura. Jos gali sutapti bet neprivalo. ai Šis puslapis skirtas VISIEMS keliams: ir pėsčiųjų, ir automobilių, ir dviračių. Šiuo metu aptariamos dviračių žymėjimo detalės yra anksčiau minėtame: https://lt.wikibooks.org/wiki/Atviro_žemėlapio_vadovas/Redagavimas/Dviračiai Sukelsiu dviračių info į anksčiau sutartą puslapį ir panaikinsiu dubliavimą. cia apzvalga, ten issamiai Perziurejes diskusijas Vokieciu ir Anglu kalbomis as radau sekancias problemas: a) radau, kad ''highway=cycleway'' laikomas senu zymejimu ir ''highway=path'' naujuoju Gal galima nuorodų? Tai tiesa, kad pėsčiųjų ir dviračių kelias žymimas kaip path su papildomomis žymomis, o štai kaip jie siūlo žymėti grynai dviračių taką? http://wiki.openstreetmap.org/w/index.php?title=DE:Bicycle/Radverkehrsanlagen_kartieren kur nors maciau ir angliskai ... Esmė: Highway=path galioja jei yra bendras kelais, tada highway=path, bicycle=yes, foot=yes, žrk. http://wiki.openstreetmap.org/wiki/DE:Key:access hg Miško/pievų takai yra tiesiog parminti/pravaikščioti takeliai. Jie nėra niekaip oficialiai pažymėti. Jie skirti tiems, kas jais sugeba praeiti/pravažiuoti - pėstieji ir dviračiai. bet ju NEgalima priskirti prie dviraciu taku, jeigu tai jie nera tam pastatyti ir zenklinti. Bet koks misko takas netaps dviraciu taku, BET dviraciu marsrutu jei jis yra marsruto dalis. Marsrutams yra LABAI svarbu priskirti ir papildomas atributus, taip apie kelio danga ir zenklinima/zymejima (tourism=information, information=*) As siulau marsrutu NEzymeti jeigu nera imanoma priskirti atsakingos jos palaikiancios organizacijos, pvz. dviraciu trasos saugomose teritorijose palaiko regioniniai ir nationaliniai parkai (ir as stengiuosi juos surinkti www.veloland.lt tinklalapyje :). Zymeti marsrutai i Belmonta i Trakus yra neoficialus. Reiketu patikrinti ir patikslinti (ir as tai padarysiu) Abėjoju, todėl jų reikia skirti prie maršrutų. Neišeis. Yra dviejų lygių informacija: 1. Kelių vektoriai, nurodantys ką matome ant žemės: dviračių taką, pesčiųjų, gatvę, pievos taką ir pan. (čia patenka ir highway=path) 2. Maršrutai - tai ryšiai, jungiantys bet kokį kiekį bet kaip išdėstytų pirmo punkto vektorių. Jie taipogi turi bendrą informaciją - kas tai per maršrutas: tipas, pavadinimas, šaltinis, aprašymas ir t.t. ir pan. (į ryšį gali būti įjungtas ir vektorius su highway=path) Taipogi misko takas yra visu pirma misko takas, kuris gali buti naudojamas bet kam, ir tik po TO jis tampa dviraciu marsruto dalimi (highway=path, route=bicycle). Man be prasmes jei kiekviena smeleta misko takeli pradesi pavadinti dviraciu taku... As radau, kad ant OCM matosi keleta marsrutu ir neoficialiu kaip belmontas ir Trakai. Jei teisingai supratau, jiems buvo priskirtos atskirios relations. Labai painu isskirti tikros trasos kaip Neries RP nuo asmeninio marsruto kaip diena aplink Trakus ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [Talk-gb-westmidlands] Fixing tag error
Hi Andy Can I ask why? Please be aware that my heritage map data relies currently on searching for artist_name Regards Brian On 21 October 2013 21:52, Andy Mabbett a...@pigsonthewing.org.uk wrote: Over the last few days, I've tagged a number of local (wider West Midlands) artworks (many newly mapped) with: artist:name instead of: artist_name Can someone remind me of the method of fixing these en mass, please? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-gb-westmidlands] Fixing tag error
Brian, I think the task was/is to change artist:name to artist_name so that it matches the existing tags used in your heritage map. Rob On 22 October 2013 17:41, Brian Prangle bpran...@gmail.com wrote: Hi Andy Can I ask why? Please be aware that my heritage map data relies currently on searching for artist_name Regards Brian On 21 October 2013 21:52, Andy Mabbett a...@pigsonthewing.org.uk wrote: Over the last few days, I've tagged a number of local (wider West Midlands) artworks (many newly mapped) with: artist:name instead of: artist_name Can someone remind me of the method of fixing these en mass, please? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-gb-westmidlands] Fixing tag error
Hi Andy, Have you got Remote Control switched on in JOSM and JOSM running? Jonathan http://bigfatfrog67.me On 22/10/2013 15:28, Andy Mabbett wrote: On 21 October 2013 23:22, Jonathan bigfatfro...@gmail.com wrote: go to taginfo page and click JOSM button for artist:name, this will load the relevant objects in JOSM. Thanks, everyone, for the advice. I've tried the above but nothing loads into JOSM. ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-se] Material om licensbytet
Gött, då ses vi där! Tyckte nog att jag kände igen ditt namn i schemat. Mvh Erik 2013-10-21 21:24, Anders Arnholm skrev: 21 okt 2013 kl. 21:17 skrev Erik Lundin e...@lists.lun.nu: Är det förresten någon annan här som kommer på FSCONS? Jepp, kommer att vara där :D ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [OSM-talk-fr] service=alley et chemin résidentiel
D'accord, merci pour vos réponses. Dans mon cas, vu qu'il s'agit d'un accès à plusieurs parcelles par lequel il est interdit de transiter, je pense le taguer : service=alley access=destination Le 21 octobre 2013 18:44, Tetsuo Shima tets...@gmail.com a écrit : Pareil que pieren pour les driveaway et alley. driveway c'est sur du terrain privé accessible uniquement aux visiteurs selon le bon vouloir de l'habitant des lieux, même si c'est pas clos. alley c'est un statut intermédiaire, qui peut etre ou pas sur du terrain privé mais qui est accessible aux public pour circuler notamment aux riverains etc. Genre les petite impasse qui desservent 3 ou 4 maisons dans les lotissement peuvent avantageusement être taggé alley plutôt que résidential. Sauf que selon le contexte je dessine ou pas les driveway. En pratique ca permet de raccorder un batiment ou autre élément a la voirie et donc a l'entrée sur la voirie qui permet l’accès au bâtiment surtout si celui ci est loin de la voie ou que sa position ne permet pas de déduire ou est l'entrée de la parcelle. Notamment pour certaine certain maison tres éloigné du la voirie principale je dessine le driveway qui informe sur l’accès, l'emplacement du numéros de rue quel bâtiment il dessert etc. Le 21 octobre 2013 12:55, Pieren pier...@gmail.com a écrit : 2013/10/21 Mathieu Schopfer mathieu.schop...@gmail.com: Merci pour avis et bonne journée, J'ai pour habitude de considérer driveway pour un accès individuel sur une propriété privée individuelle (quelque chose que je ne mappe pas personnellement) et alley lorsque ça dessert plusieurs habitations. C'est indépendant de la présence d'un nom, amha (même si driveway a peu de chance d'en avoir un). Par contre, driveway devrait systématiquement être considéré avec access=private alors que alley ne l'est pas forcément. Pour ton cas, si la voie est privée, il faut impérativement ajouter un access=private (ou access=destination) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panne des minutes diffs France
Oui, ce serveur s'est retrouvé en saturation (plus d'inodes de libres, normal vu qu'on génère environ 3 millions de fichiers par mois). J'ai fait de la place mais pas encore relancé le processus de génération des diff sur les extraits. 2013/10/22 GaelADT gael.sauva...@gmail.com Bonjour, Juste pour signaler que le serveur n'a plus l'air très à jour, il est resté bloqué au 17 octobre : http://download.openstreetmap.fr/replication/europe/france/minute/state.txt Merci d'avance, Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Panne-des-minutes-diffs-France-tp5782452.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Stand OSM dans le cadre de Capitole du Libre
Salut ! Je suis étudiant à l'N7, et donc dispo ce jour là. Je pourrais faire une démo d'une webapp en cours utilisant OpenStreetMap et discuter des possibilités. Librement, Léo Le 22/10/2013 00:53, Sébastien Dinot a écrit : Bonjour, L'édition 2013 de Capitole du Libre se déroulera les 23 et 24 novembre prochains dans les locaux de l'ENSEEIHT (N7 pour les intimes) à Toulouse : http://2013.capitoledulibre.org/ On m'a proposé d'y tenir un stand le samedi. J'ai accepté sachant que deux ateliers autour d'OSM seront en outre proposés le dimanche : * le matin : contribuer à OSM, atelier sur JOSM que j'avais déjà animé l'année dernière et qui avait connu un certain succès (25 personnes l'avaient suivi). * l'après-midi : utiliser les données d'OSM par Cyrille Giquello. Deux autres ateliers seront susceptibles d'intéresser les mappeurs : * Utilisation avancée de PostgreSQL * Leaflet, le web mapping moderne et léger Mais pour en revenir au sujet qui me préoccupe, je lance donc un appel pour l'animation du stand du samedi. Toutes les bonnes volontés, expérimentées ou non, sont les bienvenues. Et si l'animation n'est pas votre truc, je vous invite tout de même à passer pour faire connaissance. A++, Sébastien -- Léo SERRE 06.18.62.32.05 leo-serre.legtux.org signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
2013/9/13 Christian Quest cqu...@openstreetmap.fr: Il serait aussi bon d'attendre que sa diffusion sous licence LO/OL soit clairement indiquée publiquement ailleurs que dans une convention signée il y a moins d'une semaine entre l'ONEMA et l'IGN. Déterrage de vieux fil : le changement est publié depuis hier sur le site du sandre (vu sur georezo): http://www.sandre.eaufrance.fr/spip.php?page=actualiteid_rubrique=40id_article=1259 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panne des minutes diffs France
Il y a quelques temps on m'avait pris pour un idiot qund je disais que les fichiers générérés pour les (meta)tuiles étient trop petits, et que la table des inodes exploserait... C'était pourtant prévisible et bien visible dans les stats du serveur. Le 22 octobre 2013 09:19, Christian Quest cqu...@openstreetmap.fr a écrit : Oui, ce serveur s'est retrouvé en saturation (plus d'inodes de libres, normal vu qu'on génère environ 3 millions de fichiers par mois). J'ai fait de la place mais pas encore relancé le processus de génération des diff sur les extraits. 2013/10/22 GaelADT gael.sauva...@gmail.com Bonjour, Juste pour signaler que le serveur n'a plus l'air très à jour, il est resté bloqué au 17 octobre : http://download.openstreetmap.fr/replication/europe/france/minute/state.txt Merci d'avance, Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Panne-des-minutes-diffs-France-tp5782452.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Joli bug sur suivi communes
Bonjour, En regardant si de nouvelles communes vectorisées étaient à importerhttp://suivi.openstreetmap.fr/communes/communes.csv.txt, je viens de remarquer un joli bug : la première ligne (département de l'Ain) a un nom et un id qui correspond à... (je vous laisse découvrirhttp://www.openstreetmap.org/browse/relation/3264382 ). Il semblerait donc qu'il y ait un problème dans le script qui génère ce fichier, car la relation pointée a certains des tags correspondant à nos départements (type=boundary, boundary=administrative, admin_level=6). J'en déduis donc que le filtre n'est pas suffisamment précis pour ne prendre que des départements français -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Je vais me remettre sur le rendu hydro ;) Le 22 octobre 2013 13:12, Pieren pier...@gmail.com a écrit : 2013/9/13 Christian Quest cqu...@openstreetmap.fr: Il serait aussi bon d'attendre que sa diffusion sous licence LO/OL soit clairement indiquée publiquement ailleurs que dans une convention signée il y a moins d'une semaine entre l'ONEMA et l'IGN. Déterrage de vieux fil : le changement est publié depuis hier sur le site du sandre (vu sur georezo): http://www.sandre.eaufrance.fr/spip.php?page=actualiteid_rubrique=40id_article=1259 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Joli bug sur suivi communes
Bonjour, De : Francescu GAROBY Bonjour, En regardant si de nouvelles communes vectorisées étaient à importer, je viens de remarquer un joli bug : la première ligne (département de l'Ain) a un nom et un id qui correspond à... (je vous laisse découvrir). Il semblerait donc qu'il y ait un problème dans le script qui génère ce fichier, car la relation pointée a certains des tags correspondant à nos départements (type=boundary, boundary=administrative, admin_level=6). J'en déduis donc que le filtre n'est pas suffisamment précis pour ne prendre que des départements français Dans les tags communs, il y a ref=01 qui alimente bien sûr la confusion. Pour filtrer sur la France, un critère supplémentaire pourrait être : la relation départementale contient un node avec 2 propriétés : - un rôle admin_centre et - un tag ref:INSEE Ça ou autre chose tant qu'on peut éviter un is_in='France' :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Joli bug sur suivi communes
Du côté de Chypre pas moyen d'être plus précis pour l'instant concernnt sa ref (01 pour ce district chypriote) tnt qu'on n'a pas une base statistique chypriote pour indiquer ref:CY:xyz=01 au ieu de ref=01. Cependant il y déjà ISO3166-2=CY-01, et pas besoin de is_in:*=* Je ne vois pas en quoi c'est ici différent d'une division allemande, italienne, suisse, espagnole, belge, etc. Le 22 octobre 2013 14:59, V de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Francescu GAROBY Bonjour, En regardant si de nouvelles communes vectorisées étaient à importer, je viens de remarquer un joli bug : la première ligne (département de l'Ain) a un nom et un id qui correspond à... (je vous laisse découvrir). Il semblerait donc qu'il y ait un problème dans le script qui génère ce fichier, car la relation pointée a certains des tags correspondant à nos départements (type=boundary, boundary=administrative, admin_level=6). J'en déduis donc que le filtre n'est pas suffisamment précis pour ne prendre que des départements français Dans les tags communs, il y a ref=01 qui alimente bien sûr la confusion. Pour filtrer sur la France, un critère supplémentaire pourrait être : la relation départementale contient un node avec 2 propriétés : - un rôle admin_centre et - un tag ref:INSEE Ça ou autre chose tant qu'on peut éviter un is_in='France' :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Le 22 oct. 2013 à 14:50, Christian Quest cqu...@openstreetmap.fr a écrit : Je vais me remettre sur le rendu hydro ;) J'ai regardé le Drugeon (U2030500) qui passe près de chez moi : La précision du tracé est inférieur à celle d'OSM qui a été faite à partir de Bing et/ou du cadastre. Le segment qui se jette dans le Doubs n'a pas de données associées ! L'intérêt semble être son exhaustivité : Il permet de mettre un nom sur un ruisseau … ou de complété un cours d'eau … … présent dans OSM. Je peut donc importer le morceau manquant du Drugeon ? -- Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Comme pour le Route500 ça permet de compléter les données OSM mais la géométrie est trop simplifiée pour être importée. Le 22 octobre 2013 18:59, yves.prat...@laposte.net a écrit : Le 22 oct. 2013 à 14:50, Christian Quest cqu...@openstreetmap.fr a écrit : Je vais me remettre sur le rendu hydro ;) J'ai regardé le Drugeon (U2030500) qui passe près de chez moi : - La précision du tracé est inférieur à celle d'OSM qui a été faite à partir de Bing et/ou du cadastre. - Le segment qui se jette dans le Doubs n'a pas de données associées ! L'intérêt semble être son exhaustivité : - Il permet de mettre un nom sur un ruisseau … - ou de complété un cours d'eau … … présent dans OSM. Je peut donc importer le morceau manquant du Drugeon ? -- Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panne des minutes diffs France
C'est reparti... mais il y a du retard à rattraper ! Voir le graphe de retard ici: http://munin.openstreetmap.fr/pole-aquinetic.fr/osm8.openstreetmap.fr/osm_replication_lag_osmbin.html Encore un peu moins de 48h de retard. Le 22 octobre 2013 09:19, Christian Quest cqu...@openstreetmap.fr a écrit : Oui, ce serveur s'est retrouvé en saturation (plus d'inodes de libres, normal vu qu'on génère environ 3 millions de fichiers par mois). J'ai fait de la place mais pas encore relancé le processus de génération des diff sur les extraits. 2013/10/22 GaelADT gael.sauva...@gmail.com Bonjour, Juste pour signaler que le serveur n'a plus l'air très à jour, il est resté bloqué au 17 octobre : http://download.openstreetmap.fr/replication/europe/france/minute/state.txt Merci d'avance, Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Panne-des-minutes-diffs-France-tp5782452.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panne des minutes diffs France
Le 22 octobre 2013 13:34, Philippe Verdy verd...@wanadoo.fr a écrit avec son à propos habituel : Il y a quelques temps on m'avait pris pour un idiot qund je disais que les fichiers générérés pour les (meta)tuiles étient trop petits, et que la table des inodes exploserait... C'était pourtant prévisible et bien visible dans les stats du serveur. Ce serveur (osm8) ne stocke aucune (méta)tuile, uniquement des fichiers diff et ça n'a donc aucun rapport avec la discussion précédente concernant les inodes et les metatuiles d'osm103 (qui n'est que passé de 30 à 32% d'inodes depuis janvier). Ca fait du bien de plus lire de tels messages ou par erreur :) L'erreur dans le cas présent est de n'avoir pas supprimé les fichiers anciens qui n'ont plus d'intérêt au delà de quelques semaines, tout en multipliant les diff à la minute pour des extracts plus nombreux (plus d'une trentaine maintenant). Hors... 30 extracts x 2 fichiers (1 diif, 1 state) x 60 minutes x 24 heures x 30 jours... ça fait 2,6 millions de fichiers par mois. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Le 22 octobre 2013 20:51, Christian Quest cqu...@openstreetmap.fr a écrit : Comme pour le Route500 ça permet de compléter les données OSM mais la géométrie est trop simplifiée pour être importée. Et donc tu prépares bien un TMS comme pour Route500? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Oui... je m'y remet de suite ;) Le 22 octobre 2013 21:31, Romain MEHUT romain.me...@gmail.com a écrit : Le 22 octobre 2013 20:51, Christian Quest cqu...@openstreetmap.fr a écrit : Comme pour le Route500 ça permet de compléter les données OSM mais la géométrie est trop simplifiée pour être importée. Et donc tu prépares bien un TMS comme pour Route500? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Le 22 octobre 2013 21:33, Christian Quest cqu...@openstreetmap.fr a écrit : Oui... je m'y remet de suite ;) Encore merci Christian! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panne des minutes diffs France
cquest wrote C'est reparti... mais il y a du retard à rattraper ! Voir le graphe de retard ici: http://munin.openstreetmap.fr/pole-aquinetic.fr/osm8.openstreetmap.fr/osm_replication_lag_osmbin.html Encore un peu moins de 48h de retard. Merci bien :) Gaël. -- View this message in context: http://gis.19327.n5.nabble.com/Panne-des-minutes-diffs-France-tp5782452p5782515.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...
Encore une petite nouveauté en test... liée aux trottoirs dont on a parlé à plusieurs reprises. Pour cartographier l'accessibilité et les cheminements, il est malheureusement nécessaire de descendre à ce niveau de détail et d'avoir un filaire séparé de la voirie automobile. Un des problèmes (ce n'est pas le seul), c'est que ces footway viennent un peu polluer le rendu tant qu'on ne descend pas à un niveau de zoom élevé. J'ai donc tenté la chose suivante: - si highway=footway est doublé d'un footway=* (sidewalk ou crossing tels que décrits dans le wiki), ceux-ci ne sont rendus qu'à partir du zoom 19 - sinon, aucun changement. Voilà ce que ça donne par exemple à Versailles où l'on a jouté par mal de trottoirs: http://tile.openstreetmap.fr/?zoom=18lat=48.80642lon=2.13202layers=B00(nouveau) http://tile.openstreetmap.fr/?zoom=18lat=48.80642lon=2.13202layers=B00(actuel) Autre zone de test: http://tile.openstreetmap.fr/?zoom=19lat=48.80376lon=2.48536layers=B00(nouveau) Changez de zoom et alternez entre la couche osm-fr et lowzoom pour voir les différences. On peut ensuite faire une visu des cheminements accessibles en fauteuil en utilisant par exemple overpass-turbo (voir le billet de blog que j'ai écrit sur ce sujet: https://openstreetmap.fr/blogs/cquest/wheelchair-overpass) et le résultat: http://overpass-turbo.eu/s/1gy L'autre lot de nouveautés concerne les tags power=* chers à François ;) -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Stand OSM dans le cadre de Capitole du Libre
Léo SERRE a écrit : Je suis étudiant à l'N7, et donc dispo ce jour là. Parfait ! Je pourrais faire une démo d'une webapp en cours utilisant OpenStreetMap et discuter des possibilités. Toutes les démos sont bonnes à prendre. ;) Notre seule limite sera d'ordre matériel. Nous serons en effet bien loin du confort qu'ont connu les personnes qui ont animé avec moi le stand OSM lors de La Novela (4 PC portables neufs et confortables prêtés par la mairie et un accès filaire à Renater octroyé par l'université). À Capitole du Libre, nous devrons nous-même fournir le matériel, l'accès au net se fera via un accès Wifi que l'on devine passablement encombré et l'espace sera compté... A++, Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...
J'en déduis que la fameuse place Edmond Maurat (désolé) et les alentours n'ont pas leurs trottoirs taggués comme il faut ? http://tile.openstreetmap.fr/?zoom=20lat=45.43004lon=4.39497layers=B00 C'est du pointillé fin rose plutôt que les gros points gris. Greg 2013/10/22 Christian Quest cqu...@openstreetmap.fr Encore une petite nouveauté en test... liée aux trottoirs dont on a parlé à plusieurs reprises. Pour cartographier l'accessibilité et les cheminements, il est malheureusement nécessaire de descendre à ce niveau de détail et d'avoir un filaire séparé de la voirie automobile. Un des problèmes (ce n'est pas le seul), c'est que ces footway viennent un peu polluer le rendu tant qu'on ne descend pas à un niveau de zoom élevé. J'ai donc tenté la chose suivante: - si highway=footway est doublé d'un footway=* (sidewalk ou crossing tels que décrits dans le wiki), ceux-ci ne sont rendus qu'à partir du zoom 19 - sinon, aucun changement. Voilà ce que ça donne par exemple à Versailles où l'on a jouté par mal de trottoirs: http://tile.openstreetmap.fr/?zoom=18lat=48.80642lon=2.13202layers=B00(nouveau) http://tile.openstreetmap.fr/?zoom=18lat=48.80642lon=2.13202layers=B00(actuel) Autre zone de test: http://tile.openstreetmap.fr/?zoom=19lat=48.80376lon=2.48536layers=B00(nouveau) Changez de zoom et alternez entre la couche osm-fr et lowzoom pour voir les différences. On peut ensuite faire une visu des cheminements accessibles en fauteuil en utilisant par exemple overpass-turbo (voir le billet de blog que j'ai écrit sur ce sujet: https://openstreetmap.fr/blogs/cquest/wheelchair-overpass) et le résultat: http://overpass-turbo.eu/s/1gy L'autre lot de nouveautés concerne les tags power=* chers à François ;) -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...
Les gros points gris ce sont les plots (barrier=bollard). Si c'est taggué en footway=sidewalk ou footway=crossing, ça ne sera visible qu'en zoom 19 et 20 et pas avant (c'est le but). Le 22 octobre 2013 23:29, Greg ewala...@gmail.com a écrit : J'en déduis que la fameuse place Edmond Maurat (désolé) et les alentours n'ont pas leurs trottoirs taggués comme il faut ? http://tile.openstreetmap.fr/?zoom=20lat=45.43004lon=4.39497layers=B00 C'est du pointillé fin rose plutôt que les gros points gris. Greg 2013/10/22 Christian Quest cqu...@openstreetmap.fr Encore une petite nouveauté en test... liée aux trottoirs dont on a parlé à plusieurs reprises. Pour cartographier l'accessibilité et les cheminements, il est malheureusement nécessaire de descendre à ce niveau de détail et d'avoir un filaire séparé de la voirie automobile. Un des problèmes (ce n'est pas le seul), c'est que ces footway viennent un peu polluer le rendu tant qu'on ne descend pas à un niveau de zoom élevé. J'ai donc tenté la chose suivante: - si highway=footway est doublé d'un footway=* (sidewalk ou crossing tels que décrits dans le wiki), ceux-ci ne sont rendus qu'à partir du zoom 19 - sinon, aucun changement. Voilà ce que ça donne par exemple à Versailles où l'on a jouté par mal de trottoirs: http://tile.openstreetmap.fr/?zoom=18lat=48.80642lon=2.13202layers=B00(nouveau) http://tile.openstreetmap.fr/?zoom=18lat=48.80642lon=2.13202layers=B00(actuel) Autre zone de test: http://tile.openstreetmap.fr/?zoom=19lat=48.80376lon=2.48536layers=B00(nouveau) Changez de zoom et alternez entre la couche osm-fr et lowzoom pour voir les différences. On peut ensuite faire une visu des cheminements accessibles en fauteuil en utilisant par exemple overpass-turbo (voir le billet de blog que j'ai écrit sur ce sujet: https://openstreetmap.fr/blogs/cquest/wheelchair-overpass) et le résultat: http://overpass-turbo.eu/s/1gy L'autre lot de nouveautés concerne les tags power=* chers à François ;) -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Voilà un premier jet (d'eau). C'est un rendu vraiment destiné à des zooms élevés... rien de visible avant le zoom 8 (qui édite l'hydrographie en zoom 8 ?) - 8 à 11: les cours d'eau de plus de 50m de largeur à partir de 12... - tout les cours d'eau (et leur nom si il y a la place, rivière et ruisseau abrégés en riv. et rui.) et plans d'eau - la largeur du trait: fine = 0 à 15m de large, moyen (15 à 50m), gros (plus de 50m) - pointillé vert = navigable, rouge = non navigable, sans = inconnu (à vérifier, je trouve des trucs étranges) à partir du zoom 14: - les ref:sandre sont affichés sur les tronçons - les tronçons on un point noir pour indiquer leurs extrémités (changement d'attribut) - les autre POI sont indiqués avec leur description textuelle (barrages, perte, etc) Exemple: http://tile.openstreetmap.fr/?zoom=14lat=45.7921lon=4.93973layers=000B000FFTF Les couleurs sont peut être à revoir pour l'édition... j'ai pas encore testé avec JOSM. Le 22 octobre 2013 21:42, Romain MEHUT romain.me...@gmail.com a écrit : Le 22 octobre 2013 21:33, Christian Quest cqu...@openstreetmap.fr a écrit : Oui... je m'y remet de suite ;) Encore merci Christian! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BD Carthage est libre
Salut Christian, et merci pour ce boulot. Est-ce qu'il serait possible de choisir, en fond de carte, un fond blanc ? J'en cherchais un pas trop chargé, j'ai pas trouvé mon bonheur, et finalement, un fond blanc, ce serait parfois pratique. JB. Le 23.10.2013 00:48, Christian Quest a écrit : Voilà un premier jet (d'eau). C'est un rendu vraiment destiné à des zooms élevés... rien de visible avant le zoom 8 (qui édite l'hydrographie en zoom 8 ?) - 8 à 11: les cours d'eau de plus de 50m de largeur à partir de 12... - tout les cours d'eau (et leur nom si il y a la place, rivière et ruisseau abrégés en riv. et rui.) et plans d'eau - la largeur du trait: fine = 0 à 15m de large, moyen (15 à 50m), gros (plus de 50m) - pointillé vert = navigable, rouge = non navigable, sans = inconnu (à vérifier, je trouve des trucs étranges) à partir du zoom 14: - les ref:sandre sont affichés sur les tronçons - les tronçons on un point noir pour indiquer leurs extrémités (changement d'attribut) - les autre POI sont indiqués avec leur description textuelle (barrages, perte, etc) Exemple: http://tile.openstreetmap.fr/?zoom=14lat=45.7921lon=4.93973layers=000B000FFTF [1] Les couleurs sont peut être à revoir pour l'édition... j'ai pas encore testé avec JOSM. Le 22 octobre 2013 21:42, Romain MEHUT romain.me...@gmail.com a écrit : Le 22 octobre 2013 21:33, Christian Quest cqu...@openstreetmap.fra écrit : Oui... je m'y remet de suite ;) Encore merci Christian! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [2] -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ [3] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [2] Links: -- [1] http://tile.openstreetmap.fr/?zoom=14amp;lat=45.7921amp;lon=4.93973amp;layers=000B000FFTF [2] https://lists.openstreetmap.org/listinfo/talk-fr [3] http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] boundary=administrativeの県境未定箇所について
いいだです。 県域と県境を別に作る やっと理解しました(たぶん...) 地物としてのウェイは1つだけれど、それを2つ以上のリレーションに組み込む、ということですよね。 県だけではなく、市町村にも境界未確定の部分がありますので、 そういうところについても同様にしておくイメージでよいのかな。 というか、この方法を突き詰めると、 administrative boundary 全体について relation:type=boundaryが適用しづらくなってしまう気がするのですが、気のせいでしょうか。。。 ただ、この方法でも、個人的にはそれでも仕方ないかなぁ(妥協)、と思うところです。 ないよりはぜんぜんよいので。 Show-ichiさんの 未定区間をウェイであらわす妥協案 も気になるところです。 2013年10月14日 14:25 yuu hayashi hayashi@gmail.com: hayashiです。 はい、 「type=boundaryではない全く別のtypeのリレーションを定義する、ということ」です。 県域を表すリレーションと、県境を表すリレーションを別々につくります。 ・県境を表すのは relation:type=boundary でまとめあげた、閉じていないウェイ(relation: type=boundaryリレーション)にす る。リレーションには、県境が確定しているウェイのみを登録する はい、その通り。 ・県域を表すのは relation:type=boundaryを付けない、boundary = administrative もつけない、閉じたポリゴンにする。 県境の未定部分には、タグをつけないウェイを作成する。 です。 では、relation:type=? には何をつけたらいいのでしょう？ 私が調べた限りでは県域を表現する良いタグはまだ定義されていないようです。 ＞ 「データ構造が決まればレンダリングは後から定義できるので、今回はあえて考えていない」 ということでしたら、とりあえずtypeなしのリレーションでじゅうぶんです。 wiki/WikiProject_Japan/Placesのページにでもリレーションをリンクさせると良いでしょう。 技術的には、既存のjosmで簡単に作れます。 県境のリレーションを複製して、未確定部分だけWAYを補完するのが簡単ですが、どうせなら 県域のリレーションのメンバーに県境のリレーションを子リレーションとして取り込んでしまい、未確定部分だけWAYを補完します。 そうすれば、誰かが県境のWAYを修正したら、自動的に県域も更新されます。 県域リレーションを作ることによって、 1. 行政区境エリアの面積算出ができるようになる(どちらにしろ暫定面積になりますが) 2. 行政区境エリアの領域内に存在するNodeの数、などの抽出クエリを発行できるようになる で、本来の飯田さんの目的が達成できるのではないでしょうか? 2013年10月14日 12:19 Satoshi IIDA nyamp...@gmail.com: いいだです。 ＞はい、僕はレンダリングはどうでもいいです。 いいださんの立場の人が、それをいっちゃおしめえでしょう。 「データ構造が決まればレンダリングは後から定義できるので、今回はあえて考えていない」という意味だったのですが、 言葉遣いが乱暴でした。すみません。。。 「県域を表すリレーション」を「県境を表すrelation：type=boundary」 とは別に定義する 林さんの提案にある以下の内容とは別で、 type=boundaryではない全く別のtypeのリレーションを定義する、ということでしょうか。 (以下の案は選択肢1のオプションで、木村さんとほぼ同じ？ また、内容違っていたら訂正ください。) ・県域を表すのは boundary = administrative をつけた、閉じたポリゴン(relation:type=boundaryリレーション)にする。 県境の未定部分には、タグをつけないウェイを作成する ・県境を表すのは relation:type=boundary でまとめあげた、閉じていないウェイ(relation:type=boundaryリレーション)にする。 リレーションには、県境が確定しているウェイのみを登録する 仮ウェイを結合する処理 OSMのXMLデータをPostGISに入れるにはosm2pgsqlやimposmなどがよく使われますが、 その処理を行う前、 .pbfや .osmの状態のファイルに対して結合処理を行うイメージでしょうか。 (.pbfや .osm形式を直接扱うソフトウェアもありますし。 OSM DBからAPIで直接引っ張ってくるソフトウェアもありますが、それはまず脇に置いておきます) 技術としてできないことはないと思うのですが、 OSM側のオブジェクトIDやオブジェクトのバージョンが変更される可能性もあり、 差分ファイル.oscをパッチとして作っておくなどの対応も難しく、一筋縄ではゆかない印象を持っています。 また、GIS視点でいうと、ポリゴンは閉じているのが前提の形式だと認識しています。 なので、そもそもこういった処理自体がほとんど想定されていない気はします。 関連づくポイントとポイントを指定して、その2点を自動的にラインとして結合し、 なおかつラインが閉じた場合にはポリゴンとして扱う、という機能、になるかと思いますが、 もしご存知のかたいらっしゃれば教えていただけると嬉しいです m(_ _)m -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] Corporate Server Hardware Disposal
Hi Talk-GB, If anyone is aware of corporates disposing of HP DL360 G6 (or G7) servers please would you pass my details on to them. Some corporates are now disposing of their DL360 G6 servers due to the 3 year warranties running-out on these machines. These machines make perfect members of the redundant web frontend backend pools for OpenStreetMap.org. I am available in #osm-dev on IRC (oftc) http://irc.osm.org to chat. Kind regards Grant OpenStreetMap sysadmin team member. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Mapping climbing routes/areas.
Hi, Is there a current/acceptable method for mapping climbs? Each time I go to a new area and spend ages squinting at bits of rock that vaguely look like the guidebook illustration I think I must map this properly. Mainly, that's been mapping the cliff, and naming it suitably, as natural=cliff. I can only find http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Climbing which appears basically workable, if mostly ignored. Would it be reasonable to create and tag features as discussed there, acknowledging that I may need to generate my own maps if I ever want to see them rendered? Is there anyone else interested, other than the half dozen people who've commented on the talk page? Thanks, Derry (rasilon) ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Mapping climbing routes/areas.
On 22/10/13 21:58, Derry Hamilton wrote: Hi, Is there a current/acceptable method for mapping climbs? Each time I go to a new area and spend ages squinting at bits of rock that vaguely look like the guidebook illustration I think I must map this properly. Mainly, that's been mapping the cliff, and naming it suitably, as natural=cliff. I can only find http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Climbing which appears basically workable, if mostly ignored. Would it be reasonable to create and tag features as discussed there, acknowledging that I may need to generate my own maps if I ever want to see them rendered? Is there anyone else interested, other than the half dozen people who've commented on the talk page? It is a long time since did any climbing, but then all the details of a climb were in copyright books. None of the details, such as the name, route or grade, were signed at the site, so where would any of this information come from without using copyright information? How can this be verified on the ground? -- Cheers, Chris user: chillly ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-us] Meet the new board
Last night the new 2013/14 board had its first session and elected each member's roles: - Martijn van Exel - President - Kathleen Danielson - Treasurer - Ian Dees - At-Large - Mele Sax-Barnett - Vice President - Alex Barth - Secretary We're looking forward to working with everyone here to growing OpenStreetMap even better and stronger in 2014. If you'd like to share ideas, join our efforts or just have a question, please drop us a line at bo...@openstreetmap.us. Of course, I encourage everyone to join OpenStreetMap.us. It's a great way of supporting the project in the US with an annual conference, #editathons and public communications http://join.openstreetmap.us/ Announcement on the blog: http://openstreetmap.us/2013/10/meet-the-new-board/ Minutes detailing the vote on each role: http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Minutes-2013-10-21 -- Alex Barth Secretary OpenStreetMap United States Inc. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fall Editathon Seattle Edition
We had no less than two successful Editathon events here in the greater Boston area: One by Mike Foster at MIT (Cambridge), and the other one at Telenav's offices. With the recent MA building imports, missing roads at new residental developments now stand out very visibly on the map, and - with up-to-date Bing imagery and Tiger2012 - mapping those turned out to be a good task for participants. By the way, I've helped hosting a few mapping parties/editathons in the past, and one of the things I noticed this time was how much easier iD is for beginners to pick up than Potlatch. Kudos to the iD team for making a great editor!! Also, Mele, thanks for posting those great resources! We're hoping to start having more regular OSM meetups around here and that will definitely come in handy then. - Lars On 10/19/2013 09:23 PM, Melelani Sax-Barnett wrote: Things went well in PDX too-- we had about 14 people who came and went throughout the day. Lots of newbies too! I did forget to take pictures though-- oops. Feel free to use/fork our resources page and slides here: http://pdxmele.com/editathon Repo: https://github.com/pdxmele/editathon Good luck to the other meetups this weekend! My best, Mele On Sat, Oct 19, 2013 at 5:51 PM, Martijn van Exel m...@rtijn.org mailto:m...@rtijn.org wrote: Good to hear you've been having a good time! Re: battlegrid: you're most welcome! I've shown it to the folks present at the SLC Editathon today, and everyone found it useful. Please don't hesitate to send any feedback or suggestions this way. We had a really good time here in Salt Lake. The turnout was good by our standards (5 people, 2 new). We did not accomplish a lot of mapping but we did discuss a potential Utah address points import extensively. Also, because we all agreed this is a pleasant way to spend a Saturday afternoon, we are introducing a new monthly event, the Saturday Mapternoon! If you're in the area, check us out: http://www.meetup.com/osmutah/ -- Lars Ahlzen l...@ahlzen.com ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fall Editathon Seattle Edition
On Tue, Oct 22, 2013 at 2:07 PM, Lars Ahlzen l...@ahlzen.com wrote: By the way, I've helped hosting a few mapping parties/editathons in the past, and one of the things I noticed this time was how much easier iD is for beginners to pick up than Potlatch. Kudos to the iD team for making a great editor!! I concur. We started the meeting by asking new mappers to get and id and open up iD. On their own they completed the intro and then just started editing. -- Clifford OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ht] Mapping GPS à Onaville / Canaan Mars à Juin 2013
Bonjour, Effectivement il y a de la cartographie sur la zone, cela doit être COSMHA , ils ont le lien WMS (serveur OSM france) pour utiliser les images aeriennes (prisent avec un UAV) dans JOSM. A voir si ils peuvent donner plus de détail la dessus et le lien Sinon voici les données 2D (résolution 4cm) et 3D (10cm) sur la zone, prisent avec un Ebee de chez sensefly et le traitement avec le logiciel Pix4D http://wms.openstreetmap.fr/iomhaiti-files/ La source étant IOM ou Drones Adventures qui tous deux ont fait le traitement des images, suite à la mission que OSM-fr et COSMHA a organisé avec le support de IOM sur le terrain; Sauf les données sur Tisous qui émanent d'une mission avec UNOSAT et IOM en 2011 mais dans tous les cas c'est sous license Open Data compatible avec OSM. Les données sont gracieuses misent en ligne sur les Serveurs d'OSM france par Jean Guilhem, que l'on remercie au passage; Pour ma part je vais tester les DEM issue du logiciel PIX4D et du Ebee avec un laboratoire français Edytem, pour voir comment on peut améliorer nos planifications de vols et l'extraction du DEM pour l'hydro et la topo. J'en profite aussi pour dire que je vais faire les tests dans le cadre de l'association Cartonghttp://www.cartong.org/ ou nous venons de créer un groupe de bénévole pour le développement et l'utilisation de nouvelles technologies UAV et autres. En esperant que d'autres pourront compléter Le bonjour aux cartographes Haitiens, FredM ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
Re: [Talk-ht] Mapping GPS à Onaville / Canaan Mars à Juin 2013
Bonjour, Effectivement il y a de la cartographie sur la zone, cela doit etre COSMHA, ils ont un lien WMS pour utiliser les images aeriennes (prisent avec un UAV) dans JOSM. A voir si ils peuvent donner plus de détail la dessus et le lien Sinon voici les données 2D (résolution 4cm) et 3D (10cm) sur la zone, prisent avec un Ebee de chez sensefly et le traitement avec le logiciel Pix4D http://wms.openstreetmap.fr/iomhaiti-files/ La source étant IOM ou Drones Adventures qui tous deux ont fait le traitement des images; Sauf les données sur Tisous qui émanent d'une mission avec UNOSAT en 2011 mais dans tous les cas c'est sous license Open Data compatible avec OSM. Les données sont gracieuses misent en ligne sur les Serveurs d'OSM france par Jean Guilhem, que l'on remercie au passage; Pour ma part je vais tester les DEM issue du logiciel PIX4D et du Ebee avec un laboratoire français Edytem, pour voir comment on peut améliorer nos planifications de vols et l'extraction du DEM pour l'hydro et la topo. J'en profite aussi pour dire que je vais faire les tests dans le cadre de l'association Cartong http://www.cartong.org/ ou nous venons de créer un groupe de bénévole pour le développement et l'utilisation de nouvelles technologies sur le terrain. En esperant que d'autres pourront compléter Le bonjour aux cartographes Haitiens, FredM ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
