Re: [Imports] Import of Flemish Government data (building footprints and addresses)
I'm sorry to hear that and I'm sure this was not the intention of writer of the changeset comment. In this particular case, the new mapper changed the building outline to the top view base on aerial imaging, which was quite different from the footprint due to parallax. As far as I can find, the changeset has been reverted based on mutual consent between the two mappers. But I don't if the difference between the top view on aerial imaging and the foot print was explained to the new mapper. Mapping discussions like these are inevitable in OSM, independent whether the data comes from government data or not. The quality of the government data in the Netherlands is very good. But if we are aware that the government data is incorrect, we put the correct data in OSM and inform the municipality so they can update their database. The response differs between municipalities, but is generally improving. One thing that we might improve in our presentation of government data is to take the 'under investigation' flag into account and present this information to the mappers. Unfortunately that field is currently not available in the official WFS service. On 05/11/2018 21:31, Andy Townsend wrote: On 05/11/2018 19:35, Gertjan Idema wrote: We have no issue with mappers being afraid to touch buildings because of the building id's. You do have cases of new mappers being told that they are "doing it wrong" because they try and update OSM data that is (at least partially) regularly updated by imported government data, though. https://www.openstreetmap.org/changeset/63105329 is one that springs to mind (mainly because it's a buolding I've visited a very long time ago). Whatever the rights and wrongs of the situation, this mapper didn't feel able to continue in OSM. Best Regards, Andy ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
Re: [Imports] Import of Flemish Government data (building footprints and addresses)
Dear fellow-mappers, In The Netherlands we went through this process 4 years ago. This means we can talk from experience. After the preparation period, we started the real import process around march 2014 with a group of some 30 volunteers. At the end of 2014, the initial import was finished. At the time, we decided to import the building id's, but not the address id's. The address id's we not available in the WFS data source we used and we reasoned that the addresses can be identified by the address tags. Since then, we are in the process of maintaining the imported buildings and address. This concerns around 11.000 new buildings and the same number of new addresses every month. The tooling we use in this process depends highly on the building id's. Not having have the address id's seriously complicates the maintenance of addresses, Even though the combination of postcode and house number are unique in The Netherlands. Being official government id's, the building and address id's in The Netherlands get more and more official applications day by day. They are already required in notarial acts and used by the chamber of commerce. Leaving them out would not be an option in my opinion. We have no issue with mappers being afraid to touch buildings because of the building id's. Most people know where to find the id, or file an import request on the forum for a building or a block of buildings. Some complex buildings like Utrecht Central station keep being mapped manually because the official data is too complex. The main issue we have is with addresses being deleted, because people delete a node instead of the poi tags. This is nothing new, but it is detected more often because of the continuous comparison between OSM and official building and address data. Gertjan Idema On 01/11/2018 15:39, Pieter Vander Vennet wrote: Hello everyone, Original Poster here. Thanks for your remarks. A lot of peopleactivein the Belgian community are following this discussionwith interest and some bewilderment.Like the first message, this is a reply that has been written by several memberstogether. We did have a hard time filtering the actual discussion about our import from the thread. We would kindly invite everyone to take the discussion of other imports and the more philosophical points to a more appropriate place (e.g. the talk-list) and stick to the topic of the Flemish buildings import. We have been working on this for two years and don't mind working on it for a few more months, before running the actual integration. Weare, in the first place, looking for advice and guidance so as to further improve our methods - together with witha go-ahead once all issues are resolved. In case this was not clear before:this is _not_ a flat import where all the data is dumped into OSM automatically. This is an effort of the Belgian community, where mappers select a subset of the data they choose to integrate piecemeal, usually one street at a time. The data is loaded in JOSM and checked against the aerial imagery involving the mapper's common sense. As an example, this is a screenshot of the tool in action: https://matrix.org/_matrix/media/v1/download/matrix.org/WmemnfTQZOSfoKoIlByFBHmv. You can see that the tool reuses tags from OSM and is offering the mapper the choicewhich geometry should be used(by not saving the import). In combination with aerial imagery, this should cause little to no problemsin regard with the original OSM-data. Mateusz and Frederik, your points regarding documentation are being addressed as we speak. # External IDs The most discussed point seems to be the IDs we wanted to include. We believe theIDswill significantly ease updates to our buildings when the GRB is updated,and make the whole process more robust. Theyprovide a way to update and crossreference the data now and in the future.Exactly by keeping theseIDs, updating data down the road will be smoother and prevent later changes from OSM contributors to be overwritten. As an added benefit, keeping IDsmakes the import tool-agnostic. It will also make it much easier to flag errors in the source data. We aren't afraid that people will refrain from editing source-tagged objects: new users (using theiD editor) will probably not notice those tags in the first place; advanced users will know about them. And intermediate users will probably look them up. Merging and splitting are rather rare operations –once the geometry is accurate, they should becomeunnecessary operations. Finally, as the data set is available for free under an open license, anyone can verify the data independently (though noton the ground, of course). We will address the worries about the external IDs on a point by point basis below: From *Frederik Ramm:* * /If you delete a buildingthat has such an ID, how will you ensure i//t//isn't brought in againthrough a later "update import&
Re: [Imports] Importing tags for buildings
Hi Raymond, You can restrict the amount of data if you only download the required ways: http://api.openstreetmap.org/api/0.6/ways?ways=261408697,2027616672,20158063352,20158063353 etc For large datasets you might consider using a mirror of osm and/or download in batches. Groeten, Gertjan On 03/03/18 21:07, Raymond Nijssen wrote: Thank you so much, Max! This looks exactly like what I was looking for. Regards, Raymond On 03-03-18 20:42, Max Erickson wrote: A straightforward way to do it is to download the area as osm xml and then process that file to add the new tags following the JOSM file format: https://wiki.openstreetmap.org/wiki/JOSM_file_format You'd add tags to the appropriate ways and set action=modify for those ways. The round.py script here modifies an existing tag instead of adding tags, but it shows the general idea: https://github.com/maxerickson/osm-round-austin Max ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Imports-us] New Orleans: importing buildings and addresses
For an extreme example, you can have a look at Europaplein 360 - 398 in Utrecht (With an editor). Our reason for this solution is that we want to make sure that the addresses stay within the building contour. The imported dataset only guarantees that the addresses are within the building. When aligning the addresses parallel to the street, the address nodes could easily end up in a neighboring building. Also you would want to make sure the address numbers get aligned in the right direction along the street. And in The Netherlands, the addresses might be in different streets. The algorithm would get quite complex if you wanted to solve all these issues. Gertjan On Thu, 2014-10-30 at 15:47 -0500, Eric Ladner wrote: On Wed, Oct 29, 2014 at 5:29 AM, Gertjan Idema g.id...@zonnet.nl wrote: Matt, The principle dividing up multiple addresses on the same location within the building is quite simple. If there are multiple addresses on one location within a building I do the following. 1. Sort the addresses by postcode, street, house number. 2. Determine the angle of the line pointing from the address location to the center of the building. 3. From the angle and the desired distance between the address nodes, calculate a delta x an a delta y. Either or both may be negative. 4. Iterate over the address nodes and add (i * delta x) to the x coordinate an (i * delta y) to the y coordinate. If the address location is at the center of the building, I set the angle to 0. I'm having problems visualizing that in my head... Picture? If it's doing what I think it's doing, whouldn't it make more sense to align the address nodes parallel to the nearest street with the same name? -- Eric Ladner ___ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
Re: [Imports] [Imports-us] New Orleans: importing buildings and addresses
Matt, The principle dividing up multiple addresses on the same location within the building is quite simple. If there are multiple addresses on one location within a building I do the following. 1. Sort the addresses by postcode, street, house number. 2. Determine the angle of the line pointing from the address location to the center of the building. 3. From the angle and the desired distance between the address nodes, calculate a delta x an a delta y. Either or both may be negative. 4. Iterate over the address nodes and add (i * delta x) to the x coordinate an (i * delta y) to the y coordinate. If the address location is at the center of the building, I set the angle to 0. Gertjan Idema On Sun, 2014-10-26 at 23:20 +0100, Johan C wrote: 2014-10-23 2:20 GMT+02:00 Matt Toups mto...@cs.uno.edu: Johan, thank you for the kind words. Preparing this import was difficult, often tedious work! It sounds like you are in favor of keeping the building ID tags, but no ID tags on address points, which is exactly how it works currently. (Of course, others disagree. I'm glad to hear a variety of opinions on the subject.) I'm not sure I see the value in adding the exact same addr:city tag to all of the 10+ addresses I'm working with. I'm trying to keep the size down. I can trivially add this later though, if it is desired. Unfortunately there are no ZIP codes in the address data set. The idea of dividing up multiple addresses on the same location within the building is interesting. Is the source code for that available? I'd like to check it out. Fortunately it is not a common case so I hesitate to invest even more time into it. But if somebody has already solved this, great! Matt, the code for dividing up multiple address nodes with exactly the same LAT/LON coordinates is programmed somewhere (I don't know the exact spot) in this JOSM plugin code: https://github.com/gidema/josm-openservices Cheers, Johan That geofabrik tool is great, thanks. I see that it looks like the majority of existing, pre-import addr tags in my city are flagged by the tool now. In all of the cases I've seen so far, it is due to inconsistencies in the expansion of street type abbreviations. Hopefully during our import, the expanded addresses will replace these. I'll make a note for our importers to pay attention to this. Thanks! Matt ps: I just added the geofabrik link to our OSM wiki page. Of course I had to solve reCAPTCHA to save the wiki, so it looks like I just performed some addressing labor for Google... while working on my OSM addressing import! On 10/22/2014 06:01 PM, Johan C wrote: Matt, compliments to you and the others in the New Orleans community to do the valuable job of importing addresses and buildings. Some questions and recommendations: 1. In OSM it's common either to attach addresses/poi's to single building outlines (if the complete building with all floors has one address/poi) or to have them as separate nodes. Depending on local communities imports can either choose to attach nodes to building outlines or to import them as single nodes. Two factors can be important in that decision: 1) when the nola address data contains information on the entrance of a building, because it's located on or near the entrance, it would be a waste to throw away that useful info by merging that address data to the building outline without setting an entrance tag 2) you write that the nola updates of building outlines have a different frequency than the updates of addresses. Will merging address data to buildings make the update process in OSM more difficult? 2. For the updates of building outlines I can imagine that you are using ID's. OSM has no tool around yet that is able to compare OSM building outlines semi-automatically to an updated government database. A second problem is that due to various reasons (like the specialized OSM QA tools a government doesn't use) the building shapes in OSM have a good chance to vary a tiny bit from a government dataset. The - hopefully somewhere in the future to be built - tool will have to deal with these minor geometry differences in order to keep updates, after an energizing initial import, fun for mappers. Although it's true that ID's can be changed, it's
Re: [Imports] Dutch addresses and buildings import - how to deal with addresses in apartments
@Jo
I'm the developer of the plug-ins we use for the Dutch BAG import. These
plug-ins are still in development and currently only available to a
selected group of test users. With this group of 8 people, we are
testing and improving the plug-ins. On the 8th of march, we'll give a
workshop and introduce the plug-in to a larger group of interested
people.
This is the main reason that the plug-in is not yet in the JOSM's
plug-in list.
The reason that we remove the 3dshapes building outlines in most cases
instead of replacing the geometries, is that in most cases there is no 1
on 1 match between 3dshapes buildings and BAG buildings.
The 3dshapes 'buildings' are in most cases building blocks which will be
replaced by a group of bag buildings. For buildings that can be replaced
1 on 1 and that do have any history, we do use the replace geometry
option.
Here is a link for the buildings WMS you can use in Josm:
http://geodata.nationaalgeoregister.nl/bagviewer/wms?SERVICE=WMSFORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=pandSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
I'm not aware of any WMS layer containing address data. This makes sense
as a WMS layer can only show one address at a certain point, hiding all
other addresses at the same point.
You can use the bagviewer to lookup individual addresses:
http://bagviewer.geodan.nl
Gertjan Idema
It's a bit inconvenient that plugins that are needed, don't show up in
JOSM's plugin list. So I was stuck right away.
That didn't stop me from reading on. What struck me as odd, is that
the instructions say to remove the building outlines that came from
3dshapes. I know they're not worth all that much, but it seems to me
the history ought to be preserved by using replace geometry on them.
I finally created a Polyglot_Import account to help out with the
Uganda borders. Now it seems I would have to create another
Polyglot_BAG account, if I choose to take the many hurdles. I decided
to let the goblet pass...
(I know this requirement doesn't come from you, but you could make it
easier for an occasional importer like myself by providing the
necessary plugins in JOSM itself)
I want to do a street here and there, not whole villages and city
parts. The information I'm missing at the moment are the house
numbers. In Flanders we have a WMS layer we can consult to add them
manually. Is there something like that in the Netherlands?
Cheers,
Jo
2014-01-28 23:31 GMT+01:00 Johan C osm...@gmail.com:
Hi all
last November the Dutch addresses and buildings import has
been discussed on this list. Since then alpha testing has been
done in December by two people and after a new years meeting
seven members of the Dutch OpenStreetMap community are
currently beta testing a JOSM plugin which is performing the
preprocessing (conversion of the original BAG database into
the agreed tagging, simplifying building outlines and
eliminating about 99% of the crossing buildings errors) and
which is capable of loading data into JOSM by selecting a
polygon. Early March we hope to roll it out and get as much as
possible local knowledge in for importing, in order to
increase the number of active mappers in The Netherlands.
Some days ago Paul checked a testimport and stumbled across
the JOSM validator warning 'Nodes at same position'. An
example can be seen
here:
http://www.openstreetmap.org/?mlat=52.01284mlon=4.33806#map=19/52.01284/4.33806
The Vermeertoren (named after the famous Dutch painter) is a
typical Dutch high rise building of 23 floors, combining an
underground parking garage, a health care center, a child care
center (kindergarten), social and luxury housing. That means a
lot of addresses in one building. The address data as
available in the official database (the BAG) combines several
different addresses into a single LAT/LON coordinate. The WIKI
on multiple addresses
http://wiki.openstreetmap.org/wiki/Addresses is not very clear
on this situation:
Buildings with multiple house numbers
Ambox warning pn.svg There is currently no consensus on this.
This matter has not been addressed in the November proposal,
since I was not aware of it at the time. But given the WIKI we
later decided that our import method would be okay. Biggest
problems are that JOSM displays a warning (Nodes at same
position) and that the display of addresses on Mapnik is not
very nice. Perhaps the proposal as being made on this
page
http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses would
give a better solution
