We are proud to announce to the OSM community our French version of weeklyOSM.
The weeklyOSM French Team is quite new and will be presented shortly.
All the best!
http://www.weeklyosm.eu/fr/
___
talk mailing list
talk@openstreetmap.org
https://lists.op
Hi Wiktor,
If you want to automated this, you will need a database outside of
OSM, that stores the matches between the municipiality and OSM
addresses. the municipal differences over time, the OSM differences
over time. The same underlying matching algorithm previously described
is used to create
2015-01-10 16:44 GMT+01:00 Jason Remillard :
> Hi Wiktor,
>
> I don't think an address tag is needed or desirable.
>
> The best way of doing this is to compare versions of the official data
> (perhaps every 6 months), making a list of things that have changed so
> that they can be examined in OSM.
If you would go with adding ref. I'd use ref:xyz where xyz is something
which identifies who's foreign keys you are using.
For the ones that are wrong in the external source but double checked, you
could add
source=survey
or
note=resurveyed
Jo
2015-01-10 16:44 GMT+01:00 Jason Remillard :
>
On Sat, Jan 10, 2015 at 1:38 PM, Wiktor Niesiobedzki wrote:
> 3. Addresses change. Currently there is no way to isolate the
> situation, that a point in OSM needs a change of street name, city
> name or housenumber, because this name changed has changed in the
> source. I can't mark all the point
Hi Wiktor,
I don't think an address tag is needed or desirable.
The best way of doing this is to compare versions of the official data
(perhaps every 6 months), making a list of things that have changed so
that they can be examined in OSM.
Of coarse the big issue is that the matching is not tri
I'd like to add a few words on the topic.
First - the state of the OSM and sources in Poland:
1. Data sources and OSM use different standard of naming of the
streets and not always it can be mapped automatically
2. Addresses change - some addresses change cities, some change
streets, some gain str
Addresses are trivial to match by geographic proximity and the actual
values and given that addresses are one of the things that are quite
likely to move and be attached to other objects (and loose any
non-standard ref tags in the process) any tool that relies solely on
such ref tags is going to f
Documenting invalid entries in other database (adding elements only with
addr:ref and source:addr)
is a bad idea - such entries should not appear in OSM database.
Also, there seems to be a project with a similar goal, called BANO
(Base d'Adresses Nationale Ouverte). AFAIK it is covering France and
As far as I know, the tools that generates the missing address in Flanders,
does this purely based upon addr:street and addr:housenumber. Look at [1],
and fill in e.g. 1980 or 2610 as postal code , check Load OSM data and
press "update"
Documentation for end-users can be found under the documentat
Hi,
In Poland we have quite a few addresses imported from government
sources for quite long time, but as time goes on, changes are made to
the source databases, and local communities don't have any viable
tools, to track, what has changed in source. In case of city of
Skarżysko-Kamienna, local map
11 matches
Mail list logo
