Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[mmd]

On 2020-08-24 00:18, Martin Koppenhoefer wrote:
> I have recently found a lot of highway=path which clearly were tracks 
> according to aerial imagery. A tool which would allow to filter for “paths by 
> this mapper” (maybe in a similar timeframe) could speed up finding and fixing 
> them.

Probably this could be answered by an Overpass query. If you happen to
have more details, we can tell you how.

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[mmd]

On 2020-08-23 18:27, Martin Koppenhoefer wrote:
> There is a lot of stuff that could be analyzed, immense. All the history is 
> still available with all the user information...

What's next? Do we want to invite "unreliable" mappers to an exciting
two hours training course to improve their railway mapping skills? Upon
successful completion of the final test, they can earn 5 extra mapping
days that count towards their 42-day threshold for an OSMF active
contributor membership.

That's a pretty dystopian view on the OSM future, if you ask me...

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[mmd]

On 2020-08-22 19:55, Martin Koppenhoefer wrote:
> What kind of permanent ids do you want? For some more abstract concept like a 
> road with a specific name? A shop? A building? If there’s a way tagged with 
> building=supermarket, shop=supermarket, name=Foo, and you add a permanent id 
> to it. Then the supermarket gets bought by someone else and changes to 
> name=Pango? Or the supermarket closes. Or it gets torn down and rebuilt by 
> the same operator. Or someone detaches the shop tags and adds them to a node 
> inside.
> What happens with the id?

Your comment is spot on. We're discussing technical ideas for something
that isn't even clear on a semantic level.

Somehow this whole discussion reminds me of this blog post [1], in
particular the "Lack of Permanent IDs" section. A "Conceptual Object" as
it is described in that blog post sounds like a great idea, yet it
suffers from the same real world semantic issues that Martin already
pointed out.


[1] https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[mmd]

On 2020-08-22 11:08, pangoSE wrote:
> The system can then be queried lke this:
> 
> IMPLEMENTATION SUGGESTION:
> 
> GET Openstreetmap.org/api/userobjects/pangoSE
> Outputs objects for user pangoSE with the oldest first (outputs 10
> entries,  can be used to get more,  can be used to output up
> to 300 entries, _date=desc by default)

I don't think this is in any way feasible for the main API (and it
wouldn't fit its main purpose as editing API due to the analytical
nature of this request).

OTOH, I know that some people monitor dozens of boundary relations for
any changes via a single Overpass API queries. If you run your own
Overpass instance, and feed it with a list of object ids, you already
have your solution, and we can stop the discussion right here.

Transitions from "I used to be a node, and now live on as way" are more
complex to deal with. At least you would find out that the node ceases
to exist at one point.

By the way, quite a number of people have come up with your suggestion
before, and those projects always projects fail due to the sheer size of
OSM data. OWL (that was one project that was mentioned as GSoC project
in another thread) never took off exactly for that reason.

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Kostenlose OSMF-Mitgliedschaft für Aktive - Craftmapper in die OSMF ;)

[mmd]

Am 20.08.20 um 10:17 schrieb Frederik Ramm:
> ist das Spezial-Formular für "Mapper mit mindestens 42 Mappingtagen im
> letzten Jahr". Details zum Programm hier:
> https://join.osmfoundation.org/active-contributor-membership -


Wie Martijn van Exel schon auf Twitter schrieb: "Perhaps the most
significant part of this story is the recognition of non-mapping
contributions to the project."

Also, ihr 0-Tage Mapper da draußen, für euch gibt's auch eine Option,
wenn ihr das Projekt auf andere Weise vorwärts gebracht habt:

https://join.osmfoundation.org/active-contributor-membership/application-form-for-active-contributor-membership-other/

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Referential integrity of https://planet.openstreetmap.org/replication/minute//004/146/694.osc.gz

[mmd]

Am 12.08.20 um 15:40 schrieb Tom Hughes via talk:
> On 12/08/2020 13:56, Roland Olbricht via talk wrote:
> 
>> in the minute diff, in file
>> https://planet.openstreetmap.org/replication/minute//004/146/694.osc.gz
>> the way 40657824 uses node 7804408284, but that node is contained
>> neither in 694.osc.gz nor in any earlier minute diff.
> 
> It's in 693 as far as I can see?
> 
> Tom
> 

693 has been generated twice by osmosis, and Overpass API picked up the
old version. This caused multiple nodes to be missing, which caused a
subsequent crash.

See my comment here: https://github.com/drolbr/Overpass-API/issues/591

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[mmd]

On 2020-08-09 14:33, pangoSE wrote:


>> IIRC, Yuri already tried that when implementing Wikibase on our own
>> wiki, and it turned out to be massively complicated, not to say not
>> feasible at all. Didn't you follow that discussion back then?
> 
> I was not aware. Link? 
> Its not a dealbreaker for me but it would be nice to avoid confusion for non 
> SPARQL aware users.
> 

Here we go: https://phabricator.wikimedia.org/T202676


-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[mmd]

On 2020-08-09 13:05, pangoSE wrote:
> These are valid concerns. See my response to James.
> If Wikimedia should become uncooperative we could easily set up our own
> wikibase installation. See https://www.wbstack.com/

Our own Wiki.openstreetmap.org already has a wikibase installed. You're
not proposing to install another one?


> In case we take this route I would recommend having another prefix than
> Q for our unique ids.
> 

IIRC, Yuri already tried that when implementing Wikibase on our own
wiki, and it turned out to be massively complicated, not to say not
feasible at all. Didn't you follow that discussion back then?

-- 





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch

[mmd]

On 2020-08-02 11:55, Richard Fairhurst wrote:
> The other is that 
> 2020's P2 users, contrary to the cliche of 2010, are actually pretty
> skilled and experienced (by definition the beginner users use iD
> these days) - many of them have a four-figure number of 
> changesets - so installing AIR shouldn't be beyond them.

Right, my intention wasn't really to allude to any skill level (although
I agree my statement very much reads like it). It's more that casual
mappers typically have lots of other hobbies, and have limited time
available for OSM. As a consequence they'd appreciate an editor that is
easy to work with and accessible without much hassle. Flash was widely
known outside of OSM before Potlatch was available, and I believe having
Flash as a prerequisite was never much of an issue in the last 10+
years, at least initially back in ~2010.

With AIR, I just don't know. I've never used it, and I also don't know
what casual mappers will think about it. Let's be positive, and assume
installation works just like a charm :)

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[mmd]

On 2020-08-01 12:42, Richard Fairhurst wrote:
> Ruffle is showing promise (https://github.com/ruffle-rs/ruffle) and is
> under very active development, but does not yet support AS3 or the Flash
> Player features that P2 needs. I would anticipate that P2 will be able
> to run as WebAssembly when Ruffle reaches feature parity with AIR 2.6.

Yes, exactly, that's one of the two approaches I had in mind: rewriting
from scratch preferably also in Rust (which obviously wouldn't fit in
the proposed budget or timeframe), or use Ruffle with the existing code.

I'm wondering if some of the changes that are now needed for AIR would
make it more difficult to switch to Ruffle later on. I clearly see AIR
as some temporary solution to keep running even after Dec 2020, as long
as Ruffle isn't ready yet.

In a more mid-term, I really like to see a move away from such
proprietary platforms to an editor that runs in a browser
out-of-the-box. I'm a bit worried about AIR being (too) difficult to
install and run for an average Potlatch user, but that's just a gut feeling.

-- 






___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[mmd]

On 2020-08-01 10:32, Simon Poole wrote:
> That was a good decade ago, nothing that would factor in to a decision
> now (because Linux could not be a target platform to start with). 
> 

The Adobe AIR download page seems to suggest that Adobe AIR is only
available on 64-bit Windows platforms. Do we know how many of our 2500
users would fulfill that requirement?

Why aren't we porting Potlatch2 to WebAssembly, then?

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overpass API version 0.7.56

[mmd]

Thank you for the update!

On 2020-04-14 07:09, Roland Olbricht wrote:
> I intend to bundle them with the necessary changes to use
> ways and relations directly as areas,
> but that is not implemented yet.


Although this sounds like a minor topic, it has quite some impact for a
number of users. Rather frequently, people are puzzled that they cannot
query for buildings without a housenumber node inside, or residential
areas without buildings, etc.

This is mainly due to a static set of rules on the Overpass server that
define, which objects qualify for area queries. You've probably seen
various Q site answers along the lines of: in theory it would work if
your object had a name=* tag, but as it doesn't have one, sadly, you're
out of luck.

By eliminating those static rules in the equation and directly using
(almost arbitrary) ways and relations, we expect that all those new use
cases can be covered out of the box.


A few examples as sneak preview:

- https://overpass-turbo.eu/s/SP9 - unnamed landuse=residential
ways/relations without buildings inside

- https://overpass-turbo.eu/s/FaQ - misuse of barrier=line on leisure=pitch

- https://overpass-turbo.eu/s/Fbv - buildings without housenumber on way
and no respective nodes inside

(mandatory disclaimers: actual implementation and syntax *will* change,
data on the server may be outdated, server may be unavailable, prototype
only!)

-- 

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Should a deleted user's changeset list be removed?

[mmd]

> 
> As has been pointed out, the data is still there. How hard would it be
> to list these changesets as normal?

There's an open issue on GitHub for this topic, please follow up there:
https://github.com/openstreetmap/openstreetmap-website/issues/1311

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] OSM-Wiki wer ist der Admin

[mmd]

Am 10.10.19 um 17:04 schrieb Markus:
> Wer kann im OSM-Wiki die Erweiterung zur Darstellung von Formeln
> installieren?
> 

Bringe deinen Vorschlag am besten auf der Seite
https://wiki.openstreetmap.org/wiki/Talk:Wiki zunächst zur Diskussion
ein. Alles weitere ergibt sich dann.

-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Frage zu OSM-IDs

[mmd]

Am 10.10.19 um 14:52 schrieb Tom Pfeifer:
> Insbesondere wird ein Element nicht physisch gelöscht, sondern in seinem
> XML-Code das Attribut 'visible' auf 'false' gesetzt. Es wird quasi nur
> unsichtbar. Daher ist es möglich Löschungen rückgängig zu machen, also
> zu revertieren.
> 

Zu jedem Objekt gibt es auf der Datenbank einige Tabellen für die
aktuelle Version eines Objekts sowie separat davon Tabellen für
historische Objektversionen.

Beim Löschen eines Objekts werden abhängig vom Objekttyp nicht nur das
"visible" Flag auf "false" gesetzt, sondern zusätzlich auch seine Tags,
ggfs. auch Way oder Relation members gelöscht. Von dieser neuen
Objektversion wird zusätzlich eine Kopie in der Historie abgelegt.

Die Möglichkeit für einen Revert wird dadurch erreicht, dass man eine
ältere Objektversion von der API anfordert und dieses Objekt erneut mit
einer neuen (aktuellen) Versionsnummer hochlädt. Die API selbst hat
generell keine Information darüber, dass es sich um einen Revert handelt.

Redactions sind nochmal ein Sonderfall, da man hier einzelne historische
Objektversionen nicht mehr von der API abrufen kann und somit auch den
alten Stand nicht wiederherstellen kann.

-- 







___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[mmd]

Am 10.06.19 um 18:46 schrieb Yuri Astrakhan:
> and we could store other info like validation rules and even solve the
> "presets" conflict with this technology -- by storing the presets in the
> data items - community would have a direct influence on what presets
> should be. (TBD)


This idea was recently discussed on Slack US #id channel. To quote Bryan
on this: "We will never use the wikibase for our presets, sorry".

See: https://osmus.slack.com/archives/CBK3JLUJU/p1556725015059000

-- 






___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Remove validation rule asking to add highway=footway to railway/public_transport=platform

[mmd]

Am 28.05.19 um 10:32 schrieb Frederik Ramm:
> Perhaps it is possible to have a forked iD that does not work by
> meticulously cherry-picking every new change that is added to iD
> (because that would be too much work), but instead - a bit like the
> mechanisms when building a Debian or Ubunutu package - we could have
> some patches that we routinely apply to iD before it goes live on our site.

That's far too complicated. What you probably want are (mandatory)
feature toggles for every major feature as part of the iD codebase,
allowing the osm.org website repo to selectively enable/disable
controversial features in case this is really needed.

It's not beautiful but might help to establish a bit of a balances of
power without a need to have a dedicated patch team to fix up iD (which
won't work anyway).

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] We're erasing our history in wiki

[mmd]

Am 22.04.19 um 12:37 schrieb Simon Poole:
> The last functional addition to the editing API was just over a year
> ago, in March 2018.
> 
> Implying for rhetorical purposes that "nothing has changed" is rather
> disingenuous.
> 
> Simon
> 
> Am 22.04.2019 um 11:59 schrieb Ilya Zverev:
>> This attitude: “to do well we would need people responsible and there isn’t 
>> any; you can do your thing without OSM infrastructure so why bother; nobody 
>> died, stop your hype and comply” — is why we’re still with API 0.6 ten years 
>> after it was introduced.
>>

If you read his most recent blog post on
http://shtosm.ru/all/desyat-let-api/, Ilya isn't exactly suggesting that
nothing has changed since API 0.6 was introduced.

I'm quoting the English translation below:

"Is it possible to somehow change small things?

The modern API 0.6 is noticeably different from what we got ten years
ago. Around 2012, additional functions began to be attached to it that
did not affect the data model. In May 2012, applications were able to
find out what rights they have. In August, hiding versions of objects
was added to the API for relicensing. In April 2013 , notes appeared .
In November 2014 , comments were added to the editing packages . The
last time the protocol was improved six months ago, when they improved
the search for notes through / notes / search.
"


-- 





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] problems with differential update?

[mmd]

Am 11.04.19 um 21:33 schrieb Frederik Ramm:
> Hi,
> 
> On 4/11/19 21:26, Roland Olbricht wrote:
>> Could it have been that the file triggered an arcane bug in a gz library
>> from the Java universe?
> 
> Yes, that's exactly the problem - these files decompress fine with gzip,
> just not with Java.
> 

Nothing really new here. That's exactly the same thing which happened
two months ago:
https://lists.openstreetmap.org/pipermail/talk/2019-February/082057.html

Too bad osmosis is still unmaintained...

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Besorgt über den iD-Editor

[mmd]

Am 29.03.19 um 22:55 schrieb Christoph Hormann:
> On Friday 29 March 2019, mmd wrote:
>>

> Ich nehme jetzt mal an, dass das bedeuten soll, dass Quincy für Critigen 
> arbeitet.  

Ja, das ist die Einschätzung, zu der ich gelangt bin. Dieses Unternehmen
war auch im letzten Jahr auf der SotM US in Detroit mit einem Vortrag
vertreten, ist also zumindest im OSM Umfeld nicht gänzlich unbekannt:
https://2018.stateofthemap.us/program/the-map-quality-measurement-initiative-a-heat-map-approach-to-visualize-gaps-in-map-quality.html

> Das scheint ein IT-Consulting-Unternehmen zu sein 
> (https://www.critigen.com/) welches Quincy sicher nicht Vollzeit an iD 
> arbeiten lässt, weil OSM für sie Unternehmens-intern oder ihre 
> umfangreichen OSM-basierten Dienstleistungen, die sie auf ihrer 
> Webseite anbieten, so wichtig ist. ;-)

Ich denke, es ist klar, dass das Unternehmen einen recht ausgeprägten
GIS-Footprint hat und nicht nur "IT-Consulting" im klassischen Sinn macht.

> 
> Nein, es sollte für Jeden offensichtlich sein, dass Quincy das im Rahmen 
> eines Projektes für einen externen Geldgeber macht, der anonym bleiben 
> soll.

Das muss nicht unbedingt so sein, vielleicht sieht man OSM (neben den
ganzen ESRI-Themen) einfach als strategisch wichtig an und möchte sich
entsprechend positionieren. Q. arbeitet ja primär an UI/Usability
Themen, sowie dem Validator - alles Themen, die auch seit Jahren von der
Community stark nachgefragt werden.

> 
>>> Schon rein aus Sicherheits- und Haftungs-Überlegungen würde ich
>>> vorschlagen, die iD-Instanz auf osm.org umgehend auf die letzte
>>> Version zurückzusetzen, bevor diese Person commit-Rechte im
>>> iD-Repository erhalten hat.
>>
>> Ich wüsste nicht warum. Weder Quincy noch Bryan können den Code
>> direkt auf osm.org deployen. Jeder einzelne Pull Request hat eine
>> umfangreiche Dokumentation aller Änderungen, die sich jeder anschauen
>> und im Zweifelsfall entsprechend intervenieren kann.
> 
> Das kann jeder sehen, wie er möchte.  Wenn ich da in einer 
> Entscheidungs-Position in der OSMF wäre, wäre meine Frage:  Wer hat die 
> Verantwortung.  Die Sysadmins würden sich sicher sehr freuen, wenn sie 
> erfahren, dass sie das sind.  

Ich bin mir im Moment nicht einmal sicher, ob sich die OSMF mit der
Thematik überhaupt beschäftigt, und wenn ja, welche konkreten
Aktivitäten sich daraus ergeben würden.

> 
> Was glaubst Du wie groß das Geschrei wäre, wenn - rein theoretisch - 
> irgendwann herauskäme, dass das ein von der russischen/chinesischen 
> Regierung finanziertes Projekt bei Critigen ist...
> 

Interessante Vorstellung, für meinen Geschmack aber zu viel
Verschwörungstheorie ;)

-- 





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Besorgt über den iD-Editor

[mmd]

Am 29.03.19 um 23:36 schrieb Simon Poole:
> 
> Die Transparenz besteht wohl mehr darin, dass es klar ist das kein
> Dritter (der nicht Vollzeit daran arbeitet), auch nur einen Hauch einer
> Chance hat die Änderungen nachzuvollziehen, siehe
> https://github.com/openstreetmap/iD/compare/v2.14.3...master (348
> commits seit dem letzten Release im Februar).
> 

Gut, eine typische Vorgehensweise wäre, sich in der überaus
detaillierten Übersicht, die ich eingangs verlinkt hatte, zunächst einen
Überblick zu verschaffen und dann ganz gezielt in einzelne Pull Requests
zu verzweigen, für die man sich interessiert. Dort finden sich alle
Diskussionen zum Thema, so dass man das ganze auch sinnvoll im Kontext
einordnen kann und mehr über die Motivation der Änderung erfahren kann.
Meistens finden sich dort auch erklärende Bilder oder Animationen. Dass
eine Liste aller Commits ohne weitere Infos unhandlich ist, möchte ich
gar nicht in Abrede stellen.

Alle Änderungen werden auch permanent auf
http://preview.ideditor.com/master/ veröffentlicht (also mehrere Wochen
bevor sie auf osm.org landen), so dass jeder die Möglichkeit hat, früh
Rückmeldung zu geben.

Als kleiner Trost: die Tage hatte ich im Slack #id Channel gelesen, dass
2.15 die letzte Version für den Moment wird. Danach wird es größere
Umbauten geben, die mehrere Monate andauern werden und dann als neue
Version 3 veröffentlicht werden (Link:
https://osmus.slack.com/archives/CBK3JLUJU/p1553791249003600)

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Besorgt über den iD-Editor

[mmd]

Am 29.03.19 um 21:13 schrieb Christoph Hormann:
> Insbesondere die Tatsache, 
> dass da jemand das Projekt mit leitet, der für diese Arbeit von 
> jemandem anonym bezahlt wird, geht meiner Meinung nach überhaupt nicht.  

Frederik hatte das ohne weitere Belege in den Raum geworfen, allerdings
hat Quincy das sehr wohl in seinem LinkedIn-Profil aufgeführt. Umgekehrt
gilt das auch: https://twitter.com/osmquality

> Schon rein aus Sicherheits- und Haftungs-Überlegungen würde ich 
> vorschlagen, die iD-Instanz auf osm.org umgehend auf die letzte Version 
> zurückzusetzen, bevor diese Person commit-Rechte im iD-Repository 
> erhalten hat.

Ich wüsste nicht warum. Weder Quincy noch Bryan können den Code direkt
auf osm.org deployen. Jeder einzelne Pull Request hat eine umfangreiche
Dokumentation aller Änderungen, die sich jeder anschauen und im
Zweifelsfall entsprechend intervenieren kann. Mehr Transparenz geht nicht.

Beispiel: https://github.com/openstreetmap/openstreetmap-website/pull/2159


-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Relation #2632934 is "killing" differential update

[mmd]

On 2/11/19 11:41 AM, wambac...@posteo.de wrote:
> Hi,
> 
> there is a relation https://openstreetmap.org/relation/2632934, which
> currently has *42698 members*. Processing this rel with osm2pgsql fails,
> because this value is bigger than 32737 (small int).
> 

FYI: As a follow up to this discussion, the new cgimap based changeset
upload will introduce a limit of 32'000 relation members. This seems
like a good choice for many tools in the OSM ecosystem, including osm2pgsql.

See https://github.com/zerebubuth/openstreetmap-cgimap/pull/174 for
further details and discussion.

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Missing day replicate

[mmd]

On 2/11/19 12:35 PM, Jochen Topf wrote:
> On Mon, Feb 11, 2019 at 12:02:23PM +0100, Rory McCann wrote:
>> I've seen this error before a few times. I thought the file was bad and was
>> pulling my hair out trying to find the weird bytes (which didn't exist). The
>> file came from osmosis merging a few osc files together. By deleting that
>> file, osmosis would make a new one and the problem went away.
> 
> I guess its time to ditch Osmosis und switch to Osmium/PyOsmium for these
> tasks...
> 

Fully agree. This would also be good to make some progress on [1], where
 the lack of maintainers on osmosis side further complicates things, IMHO.

[1] https://github.com/openstreetmap/operations/issues/154




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Missing day replicate

[mmd]

On 2/9/19 1:58 PM, Tom Hughes wrote:
> On 09/02/2019 11:47, mmd wrote:
> 
>> For some strange reason, the gz file claims to be from "FAT filesystem",
>> and most likely osmosis can't figure out that the file contents are in
>> UTF-8.
> 
> They all say that - presumably it's just what the Java zlib
> implementation puts in the header.

Right, I would have guessed so, too.

> 
>> Once I decompress and re-compress the file on Linux, osmosis seems to be
>> just fine with said file:
> 
> I've recompressed the copy on the server now...

Thanks! I'm still not clear what the best way to fix this issue would
be. Probably this needs to be sorted out in osmosis somehow, though I
don't know where exactly. It's quite curious that this never happened
before.

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Missing day replicate

[mmd]

Am 09.02.19 um 08:17 schrieb Jochen Topf:
> 
> this might or might not be related to the hourly change file with the
> number 56107 being "strange": Osmosis can not read the file 107.osc.gz,
> it reports a UTF-8 error. But if I gunzip the file, Osmosis can read the
> file fine. So this points to an error in Osmosis' handling gzip'ed
> files. Unfortunately Osmosis is no longer maintained.
> 

For some strange reason, the gz file claims to be from "FAT filesystem",
and most likely osmosis can't figure out that the file contents are in
UTF-8.

Once I decompress and re-compress the file on Linux, osmosis seems to be
just fine with said file:


$ wget https://planet.openstreetmap.org/replication/hour/000/056/107.osc.gz

$ file 107.osc.gz
107.osc.gz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)

$ ./osmosis --read-xml-change file=107.osc.gz --write-xml-change
file=107.osc.new
...
Caused by: org.xml.sax.SAXParseException; lineNumber: 243521;
columnNumber: 1; Invalid byte 2 of 4-byte UTF-8 sequence.
...

$ gunzip 107.osc.gz

$ gzip 107.osc

$ file 107.osc.gz
107.osc.gz: gzip compressed data, was "107.osc", last modified: Wed Feb
 6 02:02:08 2019, from Unix

$ ./osmosis --read-xml-change file=107.osc.gz --write-xml-change
file=107.osc.new
-> works fine

-- 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Straßensuche auf openstreetmap.org

[mmd]

Am 19.01.19 um 09:36 schrieb Sarah Hoffmann:
> Hallo,
> 
> On Sat, Jan 19, 2019 at 08:32:33AM +0100, Martin Trautmann wrote:
>> welche bessere Suchmethode empfehlt ihr, als direkt auf
>> openstreetmap.org ins Suchfeld den Straßennamen einzugeben?
>>
>> Konkret suche ich jede Dorfstraße in der Gemeinde Mansfeld.
>>
>> Schafft ihr es, alle zehn (oder mehr) zu finden, dazu noch die vordere,
>> hintere, obere und untere?
> 
> Für Anfragen der Art "Finde mir alle..." eignet sich Overpass
> im Allgemeinen besser. Hier ist, was ich mal auf die schnelle
> mit Overpass Turbo zusammenklicken konnte:
> 
> https://overpass-turbo.eu/s/FlF
> 

Groß-/Kleinschreibung ignorieren liefert noch ein paar weitere Treffer:
https://overpass-turbo.eu/s/FlL

-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hat der Renderer Probleme?

[mmd]

Am 04.01.19 um 11:48 schrieb Manuel Reimer:

> 
> Ich habe gestern am Nachmittag einige Änderungen gemacht und einige
> davon sind bis heute nicht gerendert.
> 
> Das ging in der Vergangenheit definitiv mal schneller...
> 
> Wird aktuell besonders viel gemappt oder hat der Renderer ein Problem?
> 

Das ist ein bekanntes Problem an der Rendering-Infrastruktur, an dem die
Sysadmins kontinuierlich arbeiten und Verbesserungen vornehmen.

Wer sich für Details interessiert kann gerne das entsprechende
Operations Ticket verfolgen:
https://github.com/openstreetmap/operations/issues/257

Mehr Infos als das was dort steht habe ich auch nicht ;)

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung

[mmd]

Am 25.12.18 um 16:55 schrieb sepp1...@posteo.de:
> 
> Dank Andreas und mmd habe ich Karten gefunden, die das darstellen -
> unkompliziert und ohne Theater - das wären m.M.n. brauchbare Vorbilder
> für zukünftige Antworten von Dir?!

Kurzer Hinweis in eigener Sache: ich bin nicht damit einverstanden, dass
meine Beiträge hier dazu benutzt werden, anderen Beitragenden eine
bestimmte Form der Kommunikation nahezulegen oder in diesem Zusammenhang
als Vorbild genannt werden. Bitte in Zukunft davon Abstand nehmen. Danke.

-- 


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung

[mmd]

Am 25.12.18 um 15:21 schrieb Andreas Frey:
> Hallo Sepp, 
> falls Du eine spezialisierte Karte mit Höhenbeschränkungen benötigst könnte 
> ich Dir http://maperitive.net  empfehlen. Das läuft 
> auf dem PC und Du kannst dir Deine eigene frei konfigurierte Karte erstellen. 
> Es sollte ein leichtes sein Die von Dir gewünschten Höhenbeschränkungen damit 
> zu visualisieren. 
> 
> Grüße, 

Oder hier:
http://maxheight.bplaced.net/overpass/map.html?zoom=16=50.93688=6.96337=B000TFFF=T=line=70

FÜr Garmin gibt's noch:
https://wiki.openstreetmap.org/wiki/OSM_Transport_Karte

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gutachten [war: Re: POIs - Details - Gerichtsurteil ]

[mmd]

Am 09.11.18 um 09:23 schrieb sepp1...@posteo.de:
> Bspw. dieses Gremium im Rahmen einer Positionierung zur Umsetzung und
> Anwendung der OSM-Grundsätze und letztendlich FOSSGIS als Betreiber und
> rechtlich Verantwortlicher.
> 

Da dieser Punkt schon mehrfach von dir in diesem Faden angesprochen
wurde, würde mich mal interessieren, wie du zu dieser Einschätzung
kommst, dass FOSSGIS hier als Betreiber und rechtlich Verantwortlicher
zuständig wäre. Dir ist schon klar, dass OSMF und FOSSGIS e.V. (in der
Rolle als "OSMF - Local Chapter Germany") verschiedene Dinge sind?


-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wiki-Eintrag falsch?

[mmd]

Moin

Am 06.10.2018 um 07:45 schrieb sepp1...@posteo.de:

> Aufgrund einer Vielzahl von alten Brückenbögen sind an diesen oft
> mehrere Angaben zur Höhe zu finden, auch durch Z 265. So stehen an den
> Bogenrändern im Lot über dem Fahrbahnrand oft deutlich geringere
> Angaben, als in der Fahrbahnmitte. Vllt. sollte der Wert maxheight:
> mehrfach für ein Objekt erfassbar sein, maxheight:*, maxheight_1:* oder
> besser noch maxheigth_left:/_right:/_center: in Abhängigkeit zum
> gezeichneten Straßenrichtungsverlauf? Damit ließen sich auch Brücken
> schräg zum darunter liegenden Fahrbahnniveau eindeutig mit Höhenangaben
> versehen, das wäre gerade für die gebirgigen Regionen sicher hoch
> interessant, auch auf internationaler Ebene? So wären auch alte
> Tunnelröhren sehr gut für den Verkehr darstellbar.
> 

Das Thema maxheight wurde übrigens vor Jahren bereits ausgiebigst im
Forum diskutiert. Es gibt sogar eine Karte, die sich mit dem Thema
beschäftigt (räusper). Vielleicht schaust du auch mal in die alte
Diskussion rein:

https://forum.openstreetmap.org/viewtopic.php?pid=300099#p300099

-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[mmd]

Am 11.08.2018 um 12:18 schrieb Christoph Hormann:
> I hope you are aware that you are defending a bad tagging idea with the 
> existence of other bad tagging ideas.

The intention was actually quite the opposite. It was more a question of
taking a step back and revisiting those tags where coordinate values
already slipped in in the past where they shouldn't have.

A bit more consistency would also help arguing why we usually don't do
coordinates in tag values.

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[mmd]

Am 10.08.2018 um 19:46 schrieb Christoph Hormann:
> The idea of tagging encoded coordinates is so ridiculous to anyone with 
> a bit of understanding of computer programming, data processing and 
> data maintainance that even after ignoring all the arguments in 
> substance that have been voiced this should be universally rejected if 
> for no other reason then because it would make OSM the laughing stock 
> of the whole geodata world.

With all due respect, I think we've long crossed that point:

https://taginfo.openstreetmap.org/keys/KSJ2%3Alat
https://taginfo.openstreetmap.org/keys/ngbe%3Alat_ed50
https://taginfo.openstreetmap.org/keys/gns%3ALAT
https://taginfo.openstreetmap.org/keys/latitude

-- 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] "Nearby features" does no longer work:

[mmd]

On 08/05/18 10:18, Rainer Bielefeld wrote:
> Hello,
> 
> Tryin go use [?] - feature I get "Error contacting
> https://overpass-api.de/api/interpreter: "
> 

Hint for overpass turbo users: you should still be able to run your
queries via the HTTP URL for the time being:

http://overpass-turbo.eu

Overpass turbo uses protocol relative URLs for most Overpass servers (
e.g. "//overpass-api.de/api/"). By running overpass turbo via http, all
requests to the Overpass backend should also use HTTP.

-- 






___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Paper/Article about stagnation in OSM

[mmd]

On 08/01/18 01:08, john whelan wrote:
> The report has lots of long words but doesn't seem to grasp basic
> concepts well.
> 
> OpenStreetMap to me has two primitives, nodes and ways.  These can and
> are combined to create areas.  They have tags attached.
> 
> I honestly can't see any need for more primitives.

API 0.5 (about 11 years ago) introduced a new object type in the OSM
data model called "relations".

Contrary to common belief, there isn't such a thing as a dedicated
"Area" object type (yet). For some people this is the main reason why
OSM is stagnating and doomed to failure.

See https://wiki.openstreetmap.org/wiki/Elements

-- 





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Lua modules are here: Improving OSM wiki templates

[mmd]

Am 29.07.2018 um 14:57 schrieb Yuri Astrakhan:
> * Much better performance compared with wiki template language

Sounds great. One of the major pain points on many Wiki pages is the
whole topic around Language / LanguageSwitch templates.

Verdy_p has written a lengthy analysis of the current situation, which
I'm mostly unable to follow as I'm not really familiar with Mediawiki
internals:

https://wiki.openstreetmap.org/wiki/User_talk:Verdy_p#Performance_impact_due_to_translation_templates

Maybe someone more knowledgeable than myself could take a look, if it is
worthwhile throwing in some Lua for better performance in this case, or
maybe trying something different.

Thanks!

-- 





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] kleine Hilfestellung zu Overpass turbo

[mmd]

Am 26.07.2018 um 16:45 schrieb Kevin Hemker:
> Gibt es eine Möglichkeit da dran zu kommen?

In der Regel hat ein Gebäude keinen Namen, also gibt es keine passende
Area auf dem Overpass Server dazu. D.h. momentan geht das leider nicht
mit einer Punkt-in-Area Abfrage. Möglicherweise wird sich das in der
Zukunft noch ändern.

Es steht dir natürlich frei, eine eigene Overpass Instanz aufzusetzen
und dort die Area Creation Regeln entsprechend deiner Anforderungen
anzupassen.

-- 


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bug openstreetmap.org routing. Wer kann verifizieren? Wo melden?

[mmd]

Am 01.07.2018 um 16:59 schrieb Manuel Reimer:
> Hallo,
> [... Probleme mit Routing ...] 
> 
> Kann das jemand bestätigen? Ist das bekannt? Wo kann man das melden?
> 


Das ist ein bekanntes Problem, ich hatte vor ein paar Wochen schon ein
Issue dazu aufgemacht:
https://github.com/openstreetmap/openstreetmap-website/issues/1874


-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] overpass turbo for beginners

[mmd]

Am 19.06.2018 um 19:05 schrieb Mateusz Konieczny:
> Is there some Overpass Turbo tutorial assuming no programming or OSM
> knowledge?
> 
> I am planning to write one, I failed to find any description like this.
> 
> I am asking to avoid duplication of existing resources.
> 
> 

Take a look at the following presentation by Boris Mericskay, which is
one of the best and most up to date presentations on Overpass API and
overpass turbo I'm aware of (yes, some 0.7.55 features are missing, but
that's ok).

https://www.sites.univ-rennes2.fr/mastersigat/Cours/2018_SOTM_APIOverpass.pdf

I believe this material has also been presented at SotM France 2018
recently. It's all in French, but that shouldn't really be a big issue :)


-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Issues with diffs

[mmd]

> Since about 12 hours I'm having issues with replication.
> 
> Osmosis is reporting:
> 
> OsmosisRuntimeException: The replication state doesn't contain a
> timestamp property.
> 
> Any idea where can I post/report this?
> 

Redirect to https was activated on planet.openstreetmap.org about 12
hours ago. Seems like your osmosis still points to the http location,
and since it doesn't follow the redirect to https, it fails.

See https://github.com/openstreetmap/operations/issues/200 for details.

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Overpass-Integration meldet seit kurzem "Bad-Request" ohne Code-Änderung

[mmd]

Am 06.05.2018 um 23:34 schrieb Max Berger:
> 
> Ich hatte heute das gleiche Problem. Bisher wurde das hier akzeptiert:
> 
>  [out:xml][timeout:3000];(node["mountain_pass"="yes"];
>  node["natural"="saddle"];node["natural"="notch"];
>  node["natural"="col"]);out body;>;out meta qt;
> 
> seit 3-7 Tage bekam ich einen Fehler 400 zurück. Lösung war
> ein zusätzlicher ";" hinter "col"] und vor der Klammer
> 
>  [out:xml][timeout:3000];(node["mountain_pass"="yes"];
>  node["natural"="saddle"];node["natural"="notch"];
>  node["natural"="col"];);out body;>;out meta qt;
> 
> Keine Ahnung, ob das schon immer falsch war und akzeptiert wurde,
> Gefunden habe ichs durch Vergleich mit dem Ergebnis des Wizards von
> Overpass Turbo.
> 

Siehe https://github.com/drolbr/Overpass-API/issues/480 : in der
Overpass QL Doku waren die Semikolons schon immer drin, sie wurden
allerdings vom Server bisher nicht ganz so streng kontrolliert. Das hat
sich mit dem neuen Release vor ein paar Tagen allerdings geändert.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 22.04.2018 um 07:30 schrieb "Christian Müller":

> 
>  Änderungen in diesen Kernbereichen laufen zum jetzigen Zeitpunkt stets gegen 
> die Macht der Gewohnheit und zahllose Abhängigkeiten "downstream" an, 
> weswegen Weiterentwicklungen in der API oder der DB-Objektlogik imho am 
> besten in neuen Projekten (Forks) aufgehoben sind.  Dieses Grundkonzept 
> node/way/relation ist in der jetzigen Form doch fast eine "heilige Kuh" und 
> der API-Versionsstand in der Kategorie "never change a running system" 
> (geworden), nicht?

Da bisher alle Forks grandios gescheitert sind, halte ich davon eher
wenig. Ich glaube, jeder teilt aber die Auffassung, dass eine Änderung
am Datenmodell generell eine Sachen von mehreren Jahren ist.

Als Vorteil sehe ich, dass eine Umstellung kein Big Bang sein muss. Es
wäre z.B. möglich, einen speziell aufbereiteten Planet zusätzlich
anzubieten und einzelne Tools schrittweise umzustellen (vor allem
Router/Renderer und ähnliches). Anpassung der Editoren wird ein extrem
spannendes Thema und irgendwann dann die Migration und Umstellung der
API - eben ein Projekt für mehrere Jahre.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 21.04.2018 um 23:20 schrieb Martin Koppenhoefer:
> 
>> On 21. Apr 2018, at 20:51, Christian Müller  wrote:
>>
>> Dennoch experimentierwürdig,

> finde ich unattraktiv, da ginge ja der topologische Zusammenhalt verloren, ob 
> es eine gemeinsame Grenze ist, oder ob die Grenze “zufällig” übereinstimmt, 
> dh. man müsste umständlich herausfinden, welche Grenzen jeweils 
> zusammengehören, für bestimmte Anwendungen (z.B. muss man beim Vereinfachen 
> von Grenzen nur jeweils eine Grenze vereinfachen für beide Nachbarn, würde 
> man jeweils die Grenze unabhängig vereinfachen würde sie danach nicht mehr 
> genau zusammenpassen). Das ist nicht nur irgendein Ausnahmefall sondern die 
> Grundlage für die Vektorkarten.
> 

Ihr müsst einfach mal schauen, welche Datenmengen dahinter stecken.
Momentan schleppen wir 4,4 Milliarden Nodes mit uns herum, davon 3,8
Milliarden Nodes, die nur in irgendwelchen Ways vorkommen, ohne
Verbindung zu anderen Ways und ohne eigene Tags. Die einzige
Nutzinformation ist hier die lat/lon-Information (Metadaten klammere ich
bewusst aus, da sie für Rendering oder Routing keine Rolle spielen).

Schieben wir diese Nodes als Koordinate in den Way und löschen die alten
Nodes, werden wir augenblicklich 85% der Nodes los. Das hat massive
Auswirkungen auf Hardwareanforderungen von Tools, die mit den Daten
arbeiten wollen.

Jedes Tool muss sich momentan einen riesigen Cache aufbauen, der zu der
Node Id die entsprechenden Koordinaten zurück liefert, damit überhaupt
klar ist, wie die Geometrie eines Ways aussieht.

Zum Thema topologischer Zusammenhalt: ich hatte eingangs ja schon
angesprochen, dass wir alternativ "Verbindungs"-knoten zu anderen Ways
weiterhin als Node behalten könnten, so dass überhaupt kein Unterschied
zum jetzigen topologischen Eigenschaften entsteht (wir nennen das
einfach mal "hybrides Modell"). Ebenso könnte sich in einem rein
"Koordinaten"-basierten Modell der Editor um solche Sachen kümmern
(Details offen).

Im schon mehrmals angesprochenen OSM Samstag Workshop wurde das
Topologiethema auch groß und breit diskutiert. Ich denke, da wird es in
der Zukunft wohl noch eine textbasierte Zusammenfassung geben, in der
die Vor/Nachteile der verschiedenen Optionen detailliert beschrieben werden.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 21.04.2018 um 04:04 schrieb "Christian Müller":
>>> Wenn verklebt wird, dann wird x
>>> mal auf /die identen/ Knoten verwiesen, der Knoten (die Koordinate) aber
>>> nur exakt einmal gespeichert.  Geometrisch parallel geführte Linien
>>> erhöhen das Datenaufkommen (und den node-count in der DB) hingegen
>>> drastisch.
>> Das gilt aber auch nur für das aktuelle Datenmodell bzw. der zugehörigen
>> OSM API 0.6. Man kann sich ohne weiteres Alternativen vorstellen, in
>> denen der vermeintliche Vorteil durch Verkleben praktisch keine Rolle
>> mehr spielt, oder schlimmer noch, sich plötzlich ins Gegenteil verkehrt
>> und sogar mehr Platz benötigt.
> Das ist prinzipiell schon vorstellbar, allerdings wäre die Repräsentation
> in der Datenstruktur dann auch ähnlich, mit ähnlichen /Ungenauigkeiten/,
> da wird sich nichts plötzlich ins Gegenteil verkehren.

Mein Punkt bezog sich auf "Geometrisch parallel geführte Linien erhöhen
das Datenaufkommen (und den node-count in der DB) hingegen drastisch.".

Das hängt nun mal vom Datenmodell ab, und ja, es gibt da deutliche
Unterschiede. Daher an dieser Stelle nochmals der Verweis auf die
entsprechende Aufzeichnung vom OSM Samstag.

Soviel vorweg: sobald der "Node" nicht mehr als "Node", sondern nur noch
als Koordinate im Way existiert, bringt Verkleben keinen wirklichen
Vorteil mehr in Bezug auf den Node Count in der DB.

Verkleben wird dann wieder teurer, wenn ich gemeinsam genutzte
Koordinaten dann doch wieder als Node auspräge, um mit dem aktuellen
Modell "kompatibel" zu bleiben.

-- 





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Autobahnkilometer.ch

[mmd]

Am 20.04.2018 um 20:23 schrieb Jochen Topf:
> On Fri, Apr 20, 2018 at 07:13:16PM +0200, dktue wrote:
>> ich möchte gerne in der Schweiz die Autobahn-Kilometer pflegen und habe
>> hierfür eine Seite mit Hilfe der Overpass-API erstellt [1] (lange
>> Ladedauer!).

Ich würde mal versuchen, die Autobahnen lokal zu cachen, die ändern sich
normalerweise nicht alle 3 Sekunden. Die Milestones benötigen dann noch
4s (auf Dev-server 1s), wäre also noch ok.

>>
>> Verwundert bin ich über die errechnete Gesamtlänge des Autobahnnetzes,
>> welche laut OSM-Daten derzeit 3817 km beträgt (entspricht ungefähr 1909km
>> bei einfacher Zählung beider Fahrtrichtungen) laut offiziellen Daten jedoch
>> nur 1447 km [3]. Kann jemand diese Differenz von rund 500 km erklären?
> 
> Ich hab das mal auf andere Weise nachvollzogen: Download der Schweiz von
> der Geofbarik, dann
> 
> (das ist ein Beispielprogramm was bei libosmium dabei ist)
> 
> ergibt:
> Length: 3069.67 km
> 

Zum Vergleich noch die Gesamtlänge mit Overpass (erst ab 0.7.55):

way(area:3600051701)[highway=motorway];
make stat num=count(ways),len=sum(length());
out;

Ergibt 3040,91 km und 6563 ways.

-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 08.04.2018 um 19:37 schrieb "Christian Müller":
>>> Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten,
>>> heute scheinbar nicht mehr so wichtig.
>> Das hat die Datenbank nie kleiner gemacht. Wenn du verklebst haben ALLE
>> Wege die zusätzlichen Knoten. Tausche Anzahl Knoten gegen Anzahl Knoten
>> je Weg. Vorher hatte ich 10 Knoten in 3 Wegen. Jetzt habe ich 30 Knoten,
>> 10 je Weg.
> Oh, das ist eine Milchmädchenrechnung:  Wenn verklebt wird, dann wird x
> mal auf /die identen/ Knoten verwiesen, der Knoten (die Koordinate) aber
> nur exakt einmal gespeichert.  Geometrisch parallel geführte Linien
> erhöhen das Datenaufkommen (und den node-count in der DB) hingegen
> drastisch.

Das gilt aber auch nur für das aktuelle Datenmodell bzw. der zugehörigen
OSM API 0.6. Man kann sich ohne weiteres Alternativen vorstellen, in
denen der vermeintliche Vorteil durch Verkleben praktisch keine Rolle
mehr spielt, oder schlimmer noch, sich plötzlich ins Gegenteil verkehrt
und sogar mehr Platz benötigt.

Ich will das jetzt nicht weiter ausführen, der Thread ist eh schon viel
zu lang. Interessierte können sich gerne dazu die Aufzeichnung
"Evolution des OpenStreetMap-Datenmodells" vom OSM Samstag ansehen.

-- 












___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 05.04.2018 um 11:38 schrieb Florian Lohoff:

> On Wed, Apr 04, 2018 at 07:54:30PM +0200, Michael Reichert wrote:

>> Ich bin sehr daran interessiert, die Abstimmung mit den Füßen
>> auszuwerten, und würde mich freuen, wenn du deinen Code entweder mir zur
>> Verfügung stellen könntest oder gleich als freie Software
>> veröffentlichen könntest. Die Auswertung ist nicht ganz einfach, weil
>> man weder einfach die Objekte noch die Länge noch den Flächeninhalt
>> zählen muss, sondern auch beachten muss, wer was beigetragen hat.

> Was ich mache ist das ich mir für jeden node merke welche Wege attached
> sind. Dann gehe ich alle Wege durch (Nur die lines - also high und
> waterway) und gucke ob an 2 aufeinanderfolgenden nodes jeweils eine
> area mit derselben ID attached ist.

Netter Testfall. Ich habe mal versucht, das ganze soweit möglich mit
Turbo nachzustellen, allerdings mit der vereinfachten Annahme, dass ein
highway=* und landuse=* Way mindestens 2 gemeinsame Knoten haben müssen.
Das mit dem aufeinander folgend lässt sich leider nicht so recht abbilden.

Den Link zur Query habe ich auf folgende Github-Seite ausgelagert, weil
sich in diesem Medium nachträglich kein Post mehr ändern lässt.

https://github.com/drolbr/Overpass-API/issues/467#issuecomment-379536822

-- 





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Go Map!! Fehler beim Hochladen

[mmd]

Am 10.03.2018 um 20:28 schrieb Simon Poole:
> 
> 
> Am 10.03.2018 um 19:15 schrieb mmd:
>>
>>> Ich geb zu, dass ich das nicht explizit getestet habe, aber mindestens die 
>>> Doku zu  if-unused hat keinen Bezug zu bereits gelöschten Objekten.
>>>
>> Auch richtig, die Doku ist da nicht ganz präzise, aber die
>> Implementierung ignoriert bereits gelöschte Objekte in diesem Fall und
>> gibt keine Fehlermeldung zurück, wenn ich das richtig interpretiert habe
>> (siehe lib/diff_reader.rb):
>>
>>   if action_attributes["if-unused"]
>> begin
>>   old.delete_with_history!(new, @changeset.user)
>> rescue OSM::APIAlreadyDeletedError, OSM::APIPreconditionFailedError
>>   xml_result["new_id"] = old.id.to_s
>>   xml_result["new_version"] = old.version.to_s
>> end
>>
> Seufzz, dann gilt aber das was ich gesagt habe vermutlich anders rum (es
> ist fast mit Sicherheit nie sinnvoll if-unused in einem interaktiven
> Editor zu setzen),

Dieses if-unused Attribut wurde ursprünglich 2010 implementiert und wird
seitdem in Potlatch 2, iD und möglicherweise auch in Potlatch 1 (?)
genutzt. Für JOSM gibt es ein entsprechendes Ticket, das aber nie
umgesetzt wurde.

https://github.com/openstreetmap/iD/issues/72 hat immerhin eine halbwegs
plausible Begründung, warum man sowas machen will. Es bleibt trotzdem
ein ziemlicher hack.


> denn Node
> 
> 5457758874
> 
> ist noch Mitglied in einem Weg, irgendwas ist also schief, und Gp Map!
> bekommt so keine Fehlermeldung beim hochladen..
> 

Go Map!! hat wohl die Implikationen des Flags nicht ganz korrekt
implementiert. Aus dem diffResult-Ergebnis der API sollte sich aber
zweifelsfrei ermitteln lassen, ob das Löschen geklappt hat oder nicht.
Nur über den Grund (Objekt ist schon gelöscht vs. Objekt wird noch
verwendet) schweigt sich die API aus.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Go Map!! Fehler beim Hochladen

[mmd]

Am 10.03.2018 um 19:05 schrieb Simon Poole:
> 
> 
> Am 10. März 2018 18:21:56 MEZ schrieb mmd <mmd@gmail.com>:
>> Am 10.03.2018 um 14:07 schrieb Simon Poole:
>>> Zuerst einmal: keine Panik! Leere Aenderungsätze sind unschön aber
>> kein
>>> Beinbruch.
>>
>> und obendrein ein bekanntes Problem:
>> https://github.com/bryceco/GoMap/issues/113
> 
> Das ist das Problem auf das sich der OP bezieht (die Changesets die er 
> erstellt hat).
>>

Ja, genau. Scheint wohl auch andere Nutzer zu betreffen (ich gehe mal
davon aus, dass Helmut nicht als User "mecaro" in Moskau zugange ist. ;)


>>>
>>
>> Das osmChange enthält ja explizit , also sollte
>> der API das völlig egal sein und kein Grund für mögliche
>> Fehlermeldungen
>> sein.
> 
> Ich geb zu, dass ich das nicht explizit getestet habe, aber mindestens die 
> Doku zu  if-unused hat keinen Bezug zu bereits gelöschten Objekten.
> 

Auch richtig, die Doku ist da nicht ganz präzise, aber die
Implementierung ignoriert bereits gelöschte Objekte in diesem Fall und
gibt keine Fehlermeldung zurück, wenn ich das richtig interpretiert habe
(siehe lib/diff_reader.rb):

  if action_attributes["if-unused"]
begin
  old.delete_with_history!(new, @changeset.user)
rescue OSM::APIAlreadyDeletedError, OSM::APIPreconditionFailedError
  xml_result["new_id"] = old.id.to_s
  xml_result["new_version"] = old.version.to_s
end

-- 


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Go Map!! Fehler beim Hochladen

[mmd]

Am 10.03.2018 um 14:07 schrieb Simon Poole:
> Zuerst einmal: keine Panik! Leere Aenderungsätze sind unschön aber kein
> Beinbruch.

und obendrin ein bekanntes Problem:
https://github.com/bryceco/GoMap/issues/113

> 
> Was auffällt ist das die Nodes
> 4281597139
> und
> 3314390157
> schon gelöscht sind.
> 

Das osmChange enthält ja explizit , also sollte
der API das völlig egal sein und kein Grund für mögliche Fehlermeldungen
sein.

Allerdings fehlt im osmChange die Changeset id, so dass das XML in
dieser Forum ungültig wäre und von der API abgewiesen würde.

Weil closed source wird dir hier niemand weiterhelfen können. Es bleibt
also nur, das Problem auf Github zu melden und zu hoffen, dass sich der
Autor des Tools irgendwann drum kümmert.

https://github.com/bryceco/GoMap/issues

-- 





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Tool for tag tracking

[mmd]

Am 12.01.2018 um 14:51 schrieb Pierre Béland:
> Hi Roland. Great additions again.
> 
> I cannot access https://dev.overpass-api.de/api_new_feat/ to test.
> 
> Hi have the message Forbidden, You don't have permission to access
> /api_new_feat/ on this server.
> 

Please disregard any line starting with "{{data:overpass,server". Those
are only needed for overpass turbo to know which Overpass server to use.
You should try one of the following query shortlinks as per Roland's
post instead:

https://overpass-turbo.eu/s/uF2
https://overpass-turbo.eu/s/uF4
https://overpass-turbo.eu/s/uF7
https://overpass-turbo.eu/s/uFa


-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Length of ways

[mmd]

Am 01.12.2017 um 01:15 schrieb Andy Mabbett:
> Do we have a tool that will give me the length of a way (or a
> relation, made from several continuous ways)?
> 

The next Overpass API release will come with a handy operator to
calculate a way's length in meters.

Please check the following preview example to get a first idea on how
this will work: http://overpass-turbo.eu/s/tsJ


-- 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

[mmd]

Am 07.11.2017 um 07:29 schrieb Yuri Astrakhan:
> The tool has been thoroughly reworked, thanks to many good suggestions.
> Please keep discussion to constructive suggestions and ideas - they help
> us all move forward and reach agreement.
> 
> What's new:
> * Added "reject" vote button
> * Tasks can now offer multiple choices selection (thanks Tobias for the
> idea)
> * Added voting - experimental tasks require two users agreement to change DB

I assumed this to be a mandatory part of the new process. However, some
recent edits made by a "Serbian OSM Lint bot" [1] via your tool
indicates that you can skip pretty much all of those safeguards, and
still be able to run mass updates without any kind of voting, two user
agreement, etc. Not sure, if this is intentional, or a bug.


> * Users can "unvote" their own votes
> * Multiple changes per changeset
> * All votes are stored in the same RDF db, so the task can query it too.

> * Made it simple to revert Sophox changes: changesets now contain
> "task_id" to track task-related edits.

Also, this seems to be optional:
https://www.openstreetmap.org/changeset/53753685 has task_id =
"undefined" and was editing via Sophox 0.5. Isn't this case handled in
your tool to forbid creating such changesets in the first place?

[1] https://www.openstreetmap.org/user/Serbian%20OSM%20Lint%20bot


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Serious JOSM performance degradation

[mmd]

Am 11.11.2017 um 22:25 schrieb Safwat Halaby:
> Apparently one of my messages did not get through due to a huge file.
> Here it is once more:
> 
> More details:
> 
> JOSM 12712 has no issues.
> Latest JOSM 13053 has issues.
> Not sure how to download the intermediate version (12921).
> It's a CPU starvation issue and not a memory overuse issue. (Core at
> 100% for 10-30 seconds).
> 
> Test case:
> Open up the attached file, try editing the ref or name of a stop.
> 12712 works flawlessly.
> 13053 hangs for 10-30 seconds.
> 

I can reproduce this locally on JOSM 13106. According to jvisualvm cpu
profiling (on Oracle JDK), most time is spent in method
org.openstreetmap.josm.data.tagging.ac.AutoCompletionSet.add.

Best bet would be to create an issue on
https://josm.openstreetmap.de/newticket


-- 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

[mmd]

Am 10.11.2017 um 09:57 schrieb JB:
> oneway=no have the same meaning as no information

Very careful with removing oneway=no! Some highway=* combinations have
oneway=yes per default, and oneway=no is used to override this default
value (!!).

Obviously, removing such a oneway=no tag with the intent of getting rid
of some "redundant" data causes real damage.

The Wiki is your friend: http://wiki.openstreetmap.org/wiki/Key:oneway

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New OSM Quick-Fix service

[mmd]

Am 14.10.2017 um 11:33 schrieb Yuri Astrakhan:
> ** UPDATE: **
> 
> The service now supports "reject" button.  To use it, your query must
> contain "  #queryId:...  "  comment.  By default, when a user rejects
> something, a tag "_autoreject=id" is created. An object can have
> multiple rejected IDs. If the current query was previously rejected,
> user will no longer be able to edit the object with the same query.
> 
> Optionally, query may specify a different rejection tag with 
>  "  #rejectTag:...  ", instead of using the default "_autoreject".  I am
> still hoping for a better default name.
> 

How about creating a Wikidata entry for such a review result, and have
it point back to OSM via P402 (OpenStreetMap Relation identifier)?

Then there's only the question to create some new predicate P0815 to
store the result of an "OSM+Wikidata review", et voilà. Result available
for everyone via a public interface.

And you could easily extend it to other review apps such as osmose, by
adding even more such predicates P??? ("osmose review result", etc.).

This way we store such review data outside of OSM (where it doesn't
really belong), and everyone can benefit from it.


-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Routenplanung mit osrm

[mmd]

Am 08.10.2017 um 15:37 schrieb chris66:
> Am 08.10.2017 um 15:22 schrieb Peter Pointner:
> 
>> derzeit nicht verfügbar ist, da der bislang dafür verwendete
>> OSRM-Demoserver ohne
>> Vorwarnung vom Netz genommen wurde."
> 
> Ja, daran liegt es wohl. Andere Frage ist, wieso der Link dann auf
> openstreetmap.org nicht temporär entfernt wird oder zumindest ein
> passender Hinweis eingeblendet wird.
> 

Diesen Vorschlag gab es auch schon hier:

https://github.com/openstreetmap/openstreetmap-website/pull/1637

Nur tut sich leider recht wenig in der Sache.

-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Downloading Version 3 of all bus stops in a country

[mmd]

Am 26.09.2017 um 12:39 schrieb Safwat Halaby:
> On Tue, 2017-09-26 at 11:46 +0200, Jo wrote:

>>
>> Overpass API is definitely your friend. Version 3 doesn't mean much
>> though.
>> Do you mean all bus stops with a public_transport tag?
> 
> Thanks for the reply.
> 
> By version 3, I mean a particular historic version of the OSM element. 
> 
> For instance, see "Version #3" of this bus stop:
> 
> https://www.openstreetmap.org/node/1802982884/history
> 
> I need all "version #3" of all bus stops that have a
> "source=israel_gtfs_v1" in Israel. As far as I know. Overpass can only
> fetch the latest version. Can overpass directly fetch version #3?
> 

That's not yet possible with release 0.7.54.

A future Overpass release will allow you to filter for a specific
version of an object, which exists at a given point in time. That's
either NOW, or the date you specify via [date: ...].

A query for all version 3 objects would only work, if you can find such
a point in time, where all of those objects are valid. If there isn't
such date, you need to try several queries with varying date.

Here's some to try out in the meantime: http://overpass-turbo.eu/s/rZc


-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Overpass-Turbo rendert relations nicht korrekt

[mmd]

Am 23.09.2017 um 15:47 schrieb dktue:

> 
> ich habe ein Beispiel [1] gefunden bei dem Overpass anscheinend die
> Polygone, welche durch Grenz-Relations repräsentiert werden, nicht
> korrekt rendert.
> 

Vorab als Anmerkung: Fehlerberichte gehören in den zugehörigen Issue
Tracker, also in diesem Fall
https://github.com/tyrasd/overpass-turbo/issues bzw. besser noch
https://github.com/tyrasd/osmtogeojson/issues/

Da der Fehler nicht mehr auftritt, wenn nur noch Relationen ausgegeben
werden ( http://overpass-turbo.eu/s/rUM ), ist das wahrscheinlich das
gleiches Problem, welches hier schon bechrieben wurde:
https://github.com/tyrasd/osmtogeojson/issues/78

Unterdrückt man die doppelten Elemente, funktioniert die Darstellung
problemlos: http://overpass-turbo.eu/s/rUK

Also: bekanntes Problem.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] landuse=residential an Node

[mmd]

Am 22.09.2017 um 22:28 schrieb mmd:
> Am 22.09.2017 um 22:03 schrieb dktue:
>>
>> Jetzt würde ich gerne nicht-geschlossene ways finden, an denen
>> landuse=residential getaggt ist -- kann mir jemand sagen, wie ich das
>> mit Overpass-Turbo bewerkstelligen kann?
>>
> 
> 
> Dieses Feature ist noch nicht offiziell freigegeben und kommt irgendwann
> mit der nächsten Version:
> 

ich sollte noch ergänzen, dass is_closed() momentan nur für ways
definiert ist. Nicht dass sich da jemand wundert, warum es mit
Relationen nicht funktioniert. Das ist durchaus so beabsichtigt.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] landuse=residential an Node

[mmd]

Am 22.09.2017 um 22:03 schrieb dktue:
> 
> Jetzt würde ich gerne nicht-geschlossene ways finden, an denen
> landuse=residential getaggt ist -- kann mir jemand sagen, wie ich das
> mit Overpass-Turbo bewerkstelligen kann?
> 


Dieses Feature ist noch nicht offiziell freigegeben und kommt irgendwann
mit der nächsten Version:

http://overpass-turbo.eu/s/rTF


-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Relation zu Poly-File aus PBF

[mmd]

Am 02.09.2017 um 12:44 schrieb dktue:

> 
> Kennst jemand ein Werkzeug (oder eine Werkzeug-Kette), dass mir aus
> einer lokalen planet-PBF-Datei anhand der Relation-ID ein Poly-File
> schreibt, mit dem ich dann (mit Hilfe von osmconvert) die Regionen
> ausschneide?
> 

Osmium-Tool sollte das alles können, siehe Beispiel mit Paris und
Frankreich:
http://osmcode.org/osmium-tool/manual.html#creating-geographic-extracts


-- 


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[mmd]

Hi,

Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:

> * all ways now store "osmm:loc" with centroid coordinates, making it
> possible to crudely filter ways by location

out of curiosity, can you say a few words on how your overall approach
to calculate centroids for ways? As we all know it's an endless pain to
get that information out of minutely diffs :)

I have to say that I'm pretty much unfamiliar with SPARQL and just tried
the following query. My expectation was that I won't get any results,
making me wonder if my query has some issue?

SELECT * WHERE {
  ?osmId osmm:type 'w' .
  FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
} LIMIT 100


BTW: A quick search on Github yielded the following:
https://github.com/nyurik/osm2rdf. Would that be the right place to look
for more details?

Best,
mmd


-- 





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Draft Trademark Policy

[mmd]

Am 04.08.2017 um 19:07 schrieb Simon Poole:
> On 04.08.2017 18:07, Jochen Topf wrote:
>> On Fri, Aug 04, 2017 at 04:37:23PM +0200, Simon Poole wrote:
>>

>> I think it is totally unrealistic to expect hobby projects based on OSM
>> to ask for permission. I see three likely outcomes:
> It obviously wasn't to complicated and required lawyers to register the
> domain names in the first place and as the FAQ says we are only asking
> for the domainnames to be de-registered or given to the OSMF when they
> are no longer used for OpenStreetMap related purposes.
>>
[...]
> 
> Sorry but that is hyperbole, after the 13 years of OSM the number of
> domains affected amounts to something between 30 and 40., not 100s. The
> policy is rather clear on what is allowed and what not, and if there are
> further questions we can address that in the FAQs.

let's try to be a bit more specific here. Going through the "List of
OSM-based services" [1], I would come up with the following list of
candidates, which to my understanding would be affected in one way or
another by this Trademark Policy.

4.1. Domain names

osmarks.org, osmmosques.org, searchosm.com, osmcamera.tk
toposm.com, osmapa.pl, maps.osm2world.org, www.osm-3d.org
www.osmbuildings.org, osmocoder.de, osmlanduse.org, www.flosm.de
OsmHydrant.org, ra.osmsurround.org


5.1. Mimicking OSM sites ???

openbmap.org, openeventmap.net, openpoimap.org, openseamap.org
opensciencemap.org, openstreetphoto.org, openstreetview.org
opentouchmap.orgm, openbusinessmap.org, openwhatevermap.org
opencyclemap.org, opensnowmap.org, openstationmap.org
openwlanmap.org, openptmap.org, opengastromap.de
openlinkmap.de, openfiremap.org


Imho, it would be quite helpful to have some (possibly real world)
examples as part of the FAQ, highlighting potential issues and how to
deal with them.

Also, I'm wondering if such a policy would need a severability clause as
well?


-- 



[1] http://wiki.openstreetmap.org/wiki/List_of_OSM-based_services


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] new Wikidata+OSM data in one RDF database

[mmd]

Hi,

Am 25.05.2017 um 08:50 schrieb Yuri Astrakhan:
> The service is back up, this time with all the objects that have tags. 
> Also, I added the "has" properties on a relation - indicating all
> objects contained within the relation.  So now you can ask for a
> relation, that contains a way, and both the relation and the way have
> the same wikidata ID (something you cannot get from overpass):
> 
> http://tinyurl.com/k4vjkje
> 

Sure you can do this with overpass: http://overpass-turbo.eu/s/phj

The example returns relation 416351 along with all ways having the same
wikidata id. I commented out the part to check all relations in the
current bounding box, but I guess you'll get the idea.

best,
mmd





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Adressen ohne Karlsruhe Schema in einer AssociatedStreet-Relation

[mmd]

Hallo,

Am 17.05.2017 um 18:33 schrieb dktue:

> 
> "Finde alle Häuser die in einer AssociatedSteet-Relation enthalten sind
> aber nicht zusätzlich nach Karlsruhe Schema getaggt wurden (in einem
> definierten Gebiet)."
> 

ich war mal so frei und habe "Karlsruher Schema" nur auf die Tags
addr:street und addr:housenumber bezogen - beide dürfen nicht am Haus
dran sein:

[bbox:{{bbox}}];
rel[type=associatedStreet];
way(r:"house")[building][!"addr:street"][!"addr:housenumber"];
out geom;


Als Tipp vielleicht noch: in der Overpass Beispielsammlung gibt es
einige weitere Beispiele für associatedStreet-Relationen:

https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example#Find_useless_associatedStreet-relations

hth

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] New Overpass API v0.7.54 version

[mmd]

Hi,

your one-stop-shop wiki page for Overpass API examples has a few new
queries highlighting some recent 0.7.54 additions:

- Non-matching addr:postcode inside multiple postal code boundaries
- Adding Georeference details to village nodes
- Find duplicate nodes
- Find multipolygons with more than one outer way member
- Find relations with identical wikidata tags

See https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example

This should give you some more ideas what is possible today in addition
to what Roland already covered in his blog series.

The generalized version for "Find << n >> adjacent ways for a given
way", would also be a good fit for 0.7.54. As it still depends on a new
language element 'complete', that#s a bit of a preview only at this time:

- "Find << n >> adjacent ways" : http://overpass-turbo.eu/s/nTx

Have fun... and be sure to add your own cool examples to the Wiki page!

Cheers
mmd

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Overpass-API und Augmented-Diff-Files

[mmd]

Hi,

Am 26.11.2016 um 16:23 schrieb Pascal Neis:

> Am 26.11.16 um 10:47 schrieb mmd:
>>> Als File können diese nicht irgendwo abgerufen werden, oder?
>>
>> Augmented-diffs werden seit einiger Zeit immer nur on-the-fly erzeugt,
>> sind also nicht als File irgendwo abrufbar.
>>
>> Ich hatte mal vor einiger Zeit folgendes Script nach einer Diskussion
>> auf osm dev gebastelt ("OSM API lookups to complement minutely diffs?"
>> vom 15.09.2016). Vielleicht hilft das als Startpunkt:
> 
> danke für deine Antwort. So ähnlich mache ich das momentan bereits.

Ok, prima!

> 
> So richtig happy bin ich mit der Variante aber nicht. Ein File
> wäre deutlich schneller als jedes Mal auf die API zu warten bis
> sie das Diff erzeugt hat. Weiterhin würden dann hoffentlich auch
> keine 429er kommen. Aber ok, für meinen Workflow erstmal egal.
> 

Richtig toll skaliert der heutige Ansatz nicht. Aktuell konsumieren etwa
eine Hand voll Server regelmäßig Augmented diffs, und jeder einzelne
führt praktisch zur gleichen Zeit dieselbe Query aus. Letztlich liefert
aber jede Query idealerweise dasselbe Ergebnis, benötigt aber je nach
Fleiß der Mapper zwischen 5 und 30 Sekunden.

Ich habe mal ein Ticket dazu aufgemacht und einen anderen Ansatz
vorgeschlagen. Bitte entsprechend ergänzen ;)

https://github.com/drolbr/Overpass-API/issues/342

VG/mmd




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Overpass-API und Augmented-Diff-Files

[mmd]

Hi,

Am 26.11.2016 um 09:22 schrieb Pascal Neis:

> 
> Arbeitet jemand von euch aktiv bei/an der Overpass-API?

Ja, kann man glaube ich sagen :)

> 
> Habe einen Prototypen für die Untersuchung von OSM Edits
> entwickelt, der u.a. die Augmented Diffs[1] verwendet.
> Leider habe ich mit dem abfragen der "Files" hin und wieder
> ein paar Probleme. Nutzt von euch noch jemand diese Diffs?
> Als File können diese nicht irgendwo abgerufen werden, oder?

Augmented-diffs werden seit einiger Zeit immer nur on-the-fly erzeugt,
sind also nicht als File irgendwo abrufbar.

Ich hatte mal vor einiger Zeit folgendes Script nach einer Diskussion
auf osm dev gebastelt ("OSM API lookups to complement minutely diffs?"
vom 15.09.2016). Vielleicht hilft das als Startpunkt:

http://wiki.openstreetmap.org/wiki/User:Mmd/Augmented_Diff

Besonderheit ist, dass die aktuelle Serverlast via /api/status
ausgewertet wird. Ist dein Quota durch zuviele / zu große Queries
ausgeschöpft, wird einfach eine gewisse Wartezeit eingelegt.

Roland hatte inzwischen das Format nochmal leicht geändert, u.a. mit
einer Information, wie lange ein Script warten muss, bevor weitere
Anfragen verarbeitet werden. Das ist im Script oben allerdings noch
nicht berücksichtigt.

> 
> Die API liefert mir ab und an einen 429er (Too Many Requests).
> Obwohl ich eigentlich nicht so viele Requests hintereinander sende.

Übrigens: es gibt auch eine dedizierte ML:
http://listes.openstreetmap.fr/wws/info/overpass


-- 






___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Is Overpass falling far behind the database?

[mmd]

Am 22.11.2016 um 22:51 schrieb Ben Discoe:
> Usually, using "overpass turbo" returns results which are very recent,
> usually less than an hour.

Right, it should actually be somewhere in the range of a few minutes.

> 
> However, for the past 2 days, results seem to be very out of date.
> 
> As an example, this query: http://overpass-turbo.eu/s/kfp
> 
> returns hundreds of nodes which were moved or deleted days ago.
> 
> Is it a known issue of replication delay?
> 

Can you check your server settings in overpass turbo? Log files indicate
you're using the dev instance right now. I don't have updates running on
that particular endpoint. I would recommend to simply switch to the main
instance for up-to-date data.

hth.


-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Renderfehler Chiemsee - Alz

[mmd]

Am 14.11.2016 um 10:20 schrieb hike39:
> Hallo zusammen,
> 
> gestern habe ich auf 'OSM deutscher Stil' einen Renderfehler bei
> Seebruck am Chiemsee entdeckt. Die Alz wird da beim Abfluss aus dem
> Chiemsee nicht als Fluß dargestellt.
> 
> Bei OSM Standard (Mapnik) ist alles in Ordnung.
> 
> Wen muss man dazu ansprechen?
> 

Das Thema wurde schon ausgiebig im Forum diskutiert:

https://forum.openstreetmap.org/viewtopic.php?id=56204

Beiträge #16, #22, #27 und #32 seien dem interessierten Leser
nahegelegt. Das oben genannte Problem findet sich in anderer Form in #32
wieder, die Ursache ist dieselbe.


-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Local Overpass Issue

[mmd]

Am 19.09.2016 um 22:19 schrieb Mike Thompson:

> 
> [...technical Overpass API issue...] 


I'd suggest to post your question either on the Overpass Dev list [1] or
create an issue on Github [2] instead.

[1] http://listes.openstreetmap.fr/wws/info/overpass
[2] https://github.com/drolbr/Overpass-API/issues

-- 




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overpass XAPI URL Status

[mmd]

Hi!


Am 14.09.2016 um 09:30 schrieb Bryce Nesbitt:
> I help support a large company that uses OSM data, pulled via a specific
> query at  ://www.overpass-api.de/api/xapi
> . This query runs about once a month.

xapi endpoint is the only service that is blocked right now. That's due
to one particular mobile app firing off excessive amounts of queries.
Details are also known to the OSMF board.

You basically have two options at this time:

a) Use xapi_meta instead of xapi endpoint
b) Migrate your xapi query to Overpass XML / QL, see [1]

> 
> It recently stopped working apparently because of a hack and because of
> bogus querys:
> http://wiki.openstreetmap.org/wiki/Overpass_API/status

There was no hack in the first place. Reinstalling the server was rather
a precautionary measure.

> The comment is "I'll restore /api/xapi when this problematic access
> pattern has ceased."

The situation was last described in this ticket:

https://github.com/drolbr/Overpass-API/issues/313

I assume Roland will restore access to the xapi endpoint once that
particular app ceases to send significant amounts of queries.

-- 


[1] http://wiki.openstreetmap.org/wiki/Overpass_API/XAPI_Compatibility_Layer


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Forum admin(s) wanted

[mmd]

Hi,

Am 15.08.2016 um 16:43 schrieb Tom Hughes:


> 
> Part of the problem as I understand it is that the current site is
> running a customised code base with various patches that have never been
> passed upstream.
> 

back in November 2014, I worked with Lambertus on applying some of those
custom changes to the then current FluxBB 1.5.7. I still have them
around on Github [1]. Basically, it's a different authentication
mechanism and some UI enhancements like quick quoting, emoticons.

Somehow, those UI enhancements didn't survive the last forum update
(around Q4/2015). I believe one of the German forum moderators was
involved in that most recent update activity, but I may be wrong here.

According to my inbox, the last email conversations with Lambertus were
also in Nov 2014.

[1]
https://github.com/mmd-osm/openstreetmap-forum/commits/OpenStreetMap_forum.1.5.7



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 21:51 schrieb Michael Reichert:
> Hallo Sven,
> 
> Am 19.06.2016 um 18:05 schrieb Sven Geggus:
>> Ich lege schlichtweg Wert darauf, dass git blame auf den richtigen Menschen
>> zeigt.  Ist das so schwer zu verstehen?
> 
> Kennst du schon git commit --author "Joe Average "?
> 

In meinem Beispiel [1] ging es mir vor allem darum, dass Author und
Committer ohne weiteres auch 2 verschiedene Personen sein können, vor
allem beim cherry-picking.

Das sieht man z.B. über git log --pretty=full

commit f20766401b6375161691e3681eecbdaa8ec81f66
Author: Matt Heard 
Commit: Tom Hughes 

Fix broken link to Vagrant downloads page


Gisbert würde also weiterhin als Author für seine 3 Symbole geführt
werden und taucht so auch unter git blame auf. Mein User wäre dann
einfach nur der Committer.


[1] news://news.gmane.org:119/nk6hjt$ukp$1...@ger.gmane.org


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 18:05 schrieb Sven Geggus:
> mmd <mmd@gmail.com> wrote:
> 
>> Dachte, ich mache mich hier etwas nützlich und stelle die Vorschläge von
>> Gisbert als Pull reqeust zur Verfügung, und dann sowas... Sorry, ich bin
>> hier raus.
> 
> Das sollte Dir aber schon klar sein, dass das keine Hilfe ist wenn Du
> anderen Dinge abnimmst die sie selber lernen sollten.

Ok, nachvollziehbar.

> 
> Ich lege schlichtweg Wert darauf, dass git blame auf den richtigen Menschen
> zeigt.  Ist das so schwer zu verstehen?
> 

Schau Dir mal bitte folgenden Commit an:

https://github.com/openstreetmap/openstreetmap-website/commit/f20766401b6375161691e3681eecbdaa8ec81f66

Dort hat TomH etwas stellvertretend für Matt Heard im Projekt OSM
Website committed.

Schauen wir doch mal weiter, was `git blame` für die Datei VAGRANT.md
liefert. Richtig, Zeile 11 stammt von Matt Heard, nicht jedoch von TomH,
der das ganze commited hat.

...
b460deae (Matt Amos  2014-03-08 10:45:51 + 10)
f2076640 (Matt Heard 2016-04-04 10:56:35 +1200 11) Installers are
available for Mac OS X and Windows, please see the [Vagrant project
download page](http://www.vagrantup.com/downloads.html) for more
information.
b460deae (Matt Amos  2014-03-08 10:45:51 + 12)
...


Alles gut.

--




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 12:36 schrieb mmd:
> Am 19.06.2016 um 00:07 schrieb gmbo:
>> Am 18.06.2016 um 21:35 schrieb Sven Geggus:
>>>>> Habe heute morgen mal mit Incscape versucht die Waldsymbole zu
> 

>>
> 
> Kein Problem, ich hab die 3 Symbole aus deinen 3 Patches per
> Cherry-Picking rausgezogen und in einen neuen Pull request gepackt:
> 
> https://github.com/giggls/openstreetmap-carto-de/pull/2
> 
> Den müsste Sven nur noch commiten.
> 


Sven akzeptiert keine stellvertretenden Pull Requests, und hat diverse
weitere Anmerkungen.

Dachte, ich mache mich hier etwas nützlich und stelle die Vorschläge von
Gisbert als Pull reqeust zur Verfügung, und dann sowas... Sorry, ich bin
hier raus.

-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[mmd]

Am 19.06.2016 um 00:07 schrieb gmbo:
> Am 18.06.2016 um 21:35 schrieb Sven Geggus:
>>> >Habe heute morgen mal mit Incscape versucht die Waldsymbole zu

>> So wird das ja dann nix mit nem pull request.
>>
>> Also meine Symbole, die ich schon immer im deutschen Stil verwende und
>> die
>> Christoph als das Comic Sans der Waldsymbole empfindet finden sich hier:
>> https://github.com/giggls/openstreetmap-carto-de/tree/master/symbols-de
> Genau dort habe ich Create new file gemacht, daraufhin hat Github das
> dann bei mir angelegt. Dort sind jetzt nur die 3 Files .
> Warum deine Sachen da nicht drin sind weiß ich nicht.

Ich denke, Du müsstest wohl einen Fork auf Basis von giggls' Branch
machen (also in Github einfach oben rechts auf "Fork" klicken, nachdem
Du den Branch von giggls' aufgerufen hast). Das Ergebnis sieht dann
ungefähr so aus:

https://github.com/mmd-osm/openstreetmap-carto-de/

(oben die Erklärung: forked from giggls/openstreetmap-carto-de)


> 
> Im Moment etwas ratlos, da wieder alles nur englisch erklärt ist und 
> ich damit leider Schwierigkeiten habe.
> 

Kein Problem, ich hab die 3 Symbole aus deinen 3 Patches per
Cherry-Picking rausgezogen und in einen neuen Pull request gepackt:

https://github.com/giggls/openstreetmap-carto-de/pull/2

Den müsste Sven nur noch commiten.

Haben wir hier jemanden, der das halbwegs auf deutsch erklären kann?
Wenn ich mir das hier so durchlese, ist das bestenfalls mittelmäßiges
Denglisch. :)

--




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Overpass query to get ways longer than nodecount?

[mmd]

Am 27.05.2016 um 19:18 schrieb Richard:
> Hi,
> 
> wondering if someone knows the equivalent of JOSMs "nodes:25-" 
> in Overpass QL syntax?
> 


Hi,

see https://github.com/drolbr/Overpass-API/issues/197

Unfortunately, it's not yet implemented at this time.

If you find something missing in that issue, please feel free to enhance
the list, or maybe just add your reaction, if you think this is in some
way important to you.

hth,
mmd







___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to query Overpass to display polygons as point markers in umap?

[mmd]

Am 18.04.2016 um 01:42 schrieb Stefan Keller:
>   out body;
>   >;
>   out skel qt;
> 
> I know that the last line can be replaced by
>   out center meta;

In fact, you should replace the whole block

   out body;
   >;
   out skel qt;

by

   out center meta;

not only the last line.

Otherwise, you would first output all building-ways, resolve them to
their respective node and then output the center points of those
nodes(!), rather than returning the center point of the ways.








___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Überwachung von Edits eines Users

[mmd]

Hi,

Am 27.02.2016 um 10:24 schrieb Florian Lohoff:
> On Fri, Feb 26, 2016 at 10:40:05PM +0100, mmd wrote:
>> Hi,
>> Am 26.02.2016 um 09:23 schrieb Michael Reichert:
>>>
>>> Am 26.02.2016 um 08:50 schrieb Dietmar:
>>>> gibt es ein OSM-Tool, bei dem ich einen oder mehrere User angeben kann
>>>> und ich per Mail oder RSS oder sonstwie automatisch informiert werden
>>>> oder auf einem Blick sehen kann, ob die User in den letzten Minuten und
>>>> Stunden aktiv sind?
>>>
>>> Die Bearbeitungen eines bestimmten Users kannst du mit folgendem
>>> RSS-Feed überwachen. Früher, zu Zeiten der alten Website, war der auf
>>> Benutzerseite verlinkt, heute nicht mehr.
>>>
>>> https://www.openstreetmap.org/user/Nakaner/history
>>>
>>
>> Dieser Link führt irgendwie zur normalen OSM-Seite, zumindest kann
>> Firefox dort keinen RSS-Feed erkennen. Ich hätte hier eher so etwas
>> erwartet:
>>
>> http://www.openstreetmap.org/user/Nakaner/history/feed
> 
> Also ich hab sowohl Akregator und QuiteRSS unter Debian/GNU/Linux am
> laufen und die finden da beide einen feed 
> 

gerade nochmal nachgeschaut, in Firefox klappt das auch mit dem
ursprünglichen Link über "Lesezeichen -> Diese Seite abonnieren...".

Alles gut.

-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Überwachung von Edits eines Users

[mmd]

Hi,


Am 26.02.2016 um 09:23 schrieb Michael Reichert:
> 
> Am 26.02.2016 um 08:50 schrieb Dietmar:
>> gibt es ein OSM-Tool, bei dem ich einen oder mehrere User angeben kann
>> und ich per Mail oder RSS oder sonstwie automatisch informiert werden
>> oder auf einem Blick sehen kann, ob die User in den letzten Minuten und
>> Stunden aktiv sind?
> 
> Die Bearbeitungen eines bestimmten Users kannst du mit folgendem
> RSS-Feed überwachen. Früher, zu Zeiten der alten Website, war der auf
> Benutzerseite verlinkt, heute nicht mehr.
> 
> https://www.openstreetmap.org/user/Nakaner/history
> 

Dieser Link führt irgendwie zur normalen OSM-Seite, zumindest kann
Firefox dort keinen RSS-Feed erkennen. Ich hätte hier eher so etwas
erwartet:

http://www.openstreetmap.org/user/Nakaner/history/feed

Das war übrigens auch mal Thema im Forum:
http://forum.openstreetmap.org/viewtopic.php?id=25103

-- 





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Leerungszeiten von Briefkästen auf deutschepost.de

[mmd]

Am 20.02.2016 um 14:30 schrieb Martin Koppenhoefer:
> 
> 
>> Am 20.02.2016 um 11:30 schrieb Frederik Ramm :
>>
>> Ferner sind selbst "redigierte" Informationen immer noch in unseren
>> historischen Planetfiles enthalten (nicht im aktuellen history planet,
>> aber in älteren Dateien, die eben vor der redaction erzeugt wurden). Wir
>> haben nicht die Technik und nicht den Willen, diese Daten rückwirkend
>> alle zu ändern, aber selbst wenn wir das täten, würden immer noch
>> Mirrors von diesen alten Daten herumschwirren (die dann anders wären als
>> unsere eigenen alten Daten).
> 
> 
> für diese Mirrors müsste man dann diffs herausgegeben und Ansagen machen, 
> dass folgende herausgegebene Dateien das Copyright von X verletzen und nicht 
> unter der ODbL genutzt werden können wenn man die diffs nicht einspielt ;-)
> 


Mit dieser Frage hatte ich mich vor einem Jahr am Rande beschäftigt,
u.a. weil die minutely diffs nichts von einer Redaction mitbekommen und
bestimmte Daten weiterhin in der Overpass API auftauchen.

Damals gab es jedenfalls noch keinen Service, der das "Schwärzen" der
Daten nach außen nachvollziehbar macht.

Hier noch das Ticket: https://github.com/drolbr/Overpass-API/issues/176

-- 




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] About the development of another Overpass API

[mmd]

Dear Dongpo,

Am 26.01.2016 um 07:36 schrieb Dongpo Deng:
> Dear all,
> 
> Last year, NCHC[1] started to host a caching server 'Longma' [2] for
> serving Asia. They are now working on development of an instance of
> Overpass API in Asia. To fetch data from OSM API, we're just wondering
> which OSM APIs are available for this?
> 

a good place to discuss this topic would be the Overpass API developer
list. A lot of folks who already run their own instance are subscribed
to this list and for sure can provide some helpful insights.

http://listes.openstreetmap.fr/wws/info/overpass

Cheers
mmd




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Overpass-Turbo

[mmd]

Hallo,

Am 08.12.2015 um 19:53 schrieb Thorsten Alge:
> Hallo Liste,
> 
> vorhin war Overpass-Turbo zeitweise nicht erreichbar. Das hat sich zwar
> erledigt, aber alle meine gespeicherten Abfragen sind dabei verloren
> gegangen. Weiß jemand, wie die genau gespeichert wurden und ob da noch
> eine Chance besteht, diese wiederherzustellen?

Für den Firefox wurde das neulich im Forum beschrieben:

http://forum.openstreetmap.org/viewtopic.php?id=32224

Vielleicht hilft's ja weiter...





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Generierung von SVG mit mapweaver

[mmd]

Hallo,

Am 23.10.2015 um 19:41 schrieb Heinz-Jürgen Oertel:
> Hallo,
> 
> ich hoffe mal wieder auf Hilfe.
> Bei meiner Suche nach einem Tool um eigene Karten
> unter Linux zu erstellen
> bin ich auf Mapweaver von Gary68 gestoßen.
> Ich denke ich habe die aktuelle Version vom svn gezogen.
> 
> Einige Perl Module musste ich nachinstallieren.
> Meine Tests 
> erfolgen im Moment mit einem sehr einfachen style.txt.
> 

das Tool scheint seit etwa 3 Jahren verwaist zu sein, allerdings
funktioniert es hier immer noch unter Ubuntu 14.04, sofern man sich
genau an die Anleitung im Wiki hält [1]. Die "deprecated" Warnungen sind
wohl nicht so schlimm, jedenfalls habe ich diese nicht als
"Fehlermeldung" wahrgenommen. Ein Protokoll des Aufrufs findest Du
weiter unten in dieser Mail.

An der Stelle sei auch explizit die Frage erlaubt, warum Du nicht
einfach den "Teilen" Knopf auf osm.org nutzt und Dir direkt ein SVG
erzeugen lässt. Diese Funktion gab es m.W. vor drei Jahren noch nicht,
würde Dir wahrscheinlich das Leben deutlich einfacher machen.

Im Wiki sind noch ein paar andere Optionen für einen SVG-Export
aufgeführt: [2]. Mapweaver ist dort übrigens nicht mehr erwähnt.

Gruß,
mmd


[1] http://wiki.openstreetmap.org/wiki/Mapweaver
[2]
http://wiki.openstreetmap.org/wiki/SVG#Ways_to_create_an_SVG_map_from_OpenStreetMap


-- 

~/mapweaver$ perl mw.pl -overpass -place=Серпневе -near=Basarabeasca
-lonrad=30 -latrad=30 -size=4096 -ignorelabels
defined(@array) is deprecated at mwMap.pm line 519.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 527.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 536.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 546.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMap.pm line 555.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMulti.pm line 170.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMulti.pm line 171.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at mwMulti.pm line 296.
(Maybe you should just omit the defined()?)

mapweaver 0.48 by gary68

reading config file mwconfig.ini
1 lines read.

reading rule file yourstyle.txt
rules read: 5 nodes, 16 ways, 20 areas, 2 routes and 0 configs

Send Query 1 to overpass server..
place Серпневе found:
lon= 29.0183844
lat= 46.3040235
Send Query 2 to overpass server..
reading osm file...
read: 202589 nodes, 18682 ways and 60 relations.

drawing nodes...
drawing ways/areas...
1380 areas drawn, 4586 omitted because they are too small
1317 area labels total, 1253 omitted because belonging areas were too small
placing way labels...
processing routes...
draw multipolygons...
13 multipolygon areas drawn, 12 not drawn because they were too small.
0 multipolygon labels drawn, 0 not drawn because belonging areas were
too small.
map (34.6 cm x 34.5 cm) fits paper A2


render time (excluding all file operations) 0 hours, 0 minutes and 3 seconds

mapweaver finished after 0 hours, 1 minutes and 26 seconds




___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Parkplätze Autobahnen ohne u. mit W C

[mmd]

Hallo,

Am 09.10.2015 um 20:14 schrieb Holger Jeromin:

> 
> Evtl sind die Toiletten einzeln und nicht als Attribut auf dem
>  Rastplatz getaggt. Das könnte ein pre preprocessing finden.
>  
> Rastplätze gibt's ja jetzt auch nicht soo viele. 
> 

dafür könnte ich folgende Query anbieten: http://overpass-turbo.eu/s/bVT

Gruß
mmd


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Link-Sammlung für OSM-Stände auf Messen, Linuxtagen usw.

[mmd]

Hallo,

Am 14.09.2015 um 11:59 schrieb Michael Reichert:

> 
> Ich bin offen für Hinweise per Mail und habe auch schon per Mail und IRC
> einige erhalten. Schaut aber bitte auf dem unten stehenden Link vorbei,
> damit ich nicht denselben Hinweise mehrfach erhalte. ;-)
> 
>> Es wuerde jedenfalls schon einen gehoerigen Schritt weiter helfen,
>> wenn man die bookmarks.html nicht abspeichern muesste um sie zu
>> oeffnen, sondern wenn der Browser die Datei direkt als HTML rendern
>> wuerde. (Dazu koennte man das git-Repo regelmaessig auschecken und
>> die Datei bookmarks.html an einer merkbaren URL auf einem Webserver
>> ablegen. Falls das niemand von euch umsetzen will, werde ich das
>> selbst machen ... aber dann muss man sich halt nochmal einen neuen
>> Domainname merken.)
> 
> http://michreichert.de/projects/trade-fair-bookmark-collection/bookmarks.html
> 

richte doch einfach einen Branch "gh-pages" ein, dann kriegst Du das
Hosting direkt auf GitHub geschenkt und musst dich nie mehr um das
Updaten deiner Seite kümmern.

Hier mal ein Beispiel für mein geforktes Repository:

http://mmd-osm.github.io/trade-fair-bookmark-collection/bookmarks.html

Gruß,
mmd



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[OSM-talk] Buildings on abandoned railways (via Overpass) (was: Re: THIS is the kind of enthusiasm some would reject)

[mmd]

Hi,

Am 13.09.2015 um 00:47 schrieb Jo:

> 
> I also tried not to comment, but I'm in that same camp. There is really
> no harm in having abandoned and even raised railways, unless buildings
> are constructed over them.
> 

out of curiosity I was wondering a bit, if there are lots of abandoned
railways with plenty of buildings in the way, i.e. is this really a
widespread issue?

I put up an Overpass query to get some insights for my area. It turned
out to be only a few buildings, which I can happily ignore. Not sure
about those cases, where they cross a motorway, though...

See for yourself in your area:

http://overpass-turbo.eu/s/bpP

Rather than looking at the whole planet at once, I'd recommend to start
out with a somewhat smaller bbox. This query runs on a Overpass Lab
preview (read: beta) version with some real hard disks underneath. So be
prepared for some potential issues here and there ;)

Kind regards,
mmd





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] "Enclosing feature" on osm.org broken ?

[mmd]

Hi,

Am 12.09.2015 um 10:39 schrieb Marc Gemis:
> I recently saw two independent reports [1][2] from people that complain
> that the list of "Enclosing Features" is returning a number of
> North-African towns for features in The Netherlands.

> I checked the boundaries of those administrative units in e.g. Algeria
> and did not notice anything suspicious. They were unaltered for 9 months
> or longer.
> 
> Anyone knows what is going on ?

yes, that's an Overpass API issue, which has also been reported on
GitHub [1]. Roland is already informed and started to recreate the areas
from scratch.

Please check the Overpass status wiki page for any updates [2].

If you're impacted by this behavior in Overpass turbo, simply switch to
another instance, like rambler. For the "enclosing feature" on the main
page, that's unfortunately not possible, afaik.

Kind regards,
mmd


[1] https://github.com/drolbr/Overpass-API/issues/228
[2] http://wiki.openstreetmap.org/wiki/Overpass_API/status




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Overpass-Turbo

[mmd]

Hallo Thorsten,

Am 25.05.2015 um 14:08 schrieb Thorsten Alge:

 Bei der Abfrage nach den selben Elementen in der Relation Galway erhalte
 ich aber alle Elemete. Auch jene, welche ein name:ga Tag haben. Ich
 verstehe allerdings nicht ganz warum.
 
 [out:json][timeout:25];
 area[name=Galway];
 (
   node(area)[place][name]-
   node(area)[name:ga]
 );
 out body;
 ;
 out skel qt;
 
 Kann mir Jemand einen Hinweis geben?
 

Gerne doch. Im Beispiel oben bezieht sich (area) jeweils auf das
Default-Inputset. Das ist einfach eine nicht näher benannten Menge, die
die gerade zu bearbeitenden Knoten, Wegen, Relationen sowie Areas enthält.

Ausgeschrieben würde das dann so aussehen:

   node(area._)[place][name]- (1)
   node(area._)[name:ga](2)

Schauen wir uns für beide Zeilen einmal an, was jeweils an Elementen als
Eingabe berücksichtigt wird und wie die Ergebnismenge aussieht:

Zeile (1)
-

 Input:  Area Galway, noch aus dem vorhergehenden area[name=Galway];

 Output: Nodes mit [place][name]. Die Area wird nicht übernommen!


(Output ist gleichzeitig Input für die nächste Zeile)


Zeile (2)
-

 Input:  Nodes mit [place][name]

 Output: Da in ._ keine Area enthalten ist, liefert (area._)
 eine leere Menge zurück!

Beheben lässt sich das ganze, indem man die ursprüngliche Area in eine
Variable packt (hier .a) und man sich später wieder darauf bezieht.

[out:json][timeout:25];
area[name=Galway]-.a;
(
  node(area.a)[place][name]; -
  node(area.a)[name:ga];
);
out body;
  ;
out skel qt;

Ich hoffe, das war soweit einigermaßen verständlich. Wenn nicht: ich
habe das Thema schon einmal vorsorglich für die neue Overpass API
Learning Platform vorgeschlagen, die im Rahmen des GSoc 2015 entsteht :)

Gruß,
mmd


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Eigene OSM-Karte mit Overpass

[mmd]

Hallo Roland, Harald,

Am 11.05.2015 um 19:01 schrieb Roland Olbricht:
 Es sieht eher danach aus, als wenn Briefkästen dann nicht gefunden 
 werden. Es scheint mir beim Drüberschauen vielleicht doch ein
 Problem der briefkastenkarte.de zu sein, weil das Problem auf der
 Beispielseite des Leaflet-Plugins nicht auftritt.

Ich meine mich zu erinnern, dass diese Leaflet-Beispielseite noch auf
die rambler.ru-Instanz zugreift und dort diese Limitierung (noch)
nicht greift.


Am 11.05.2015 um 21:06 schrieb Harald Hartmann:
 danke für deine generelle Maßnahmen, werde davon sicherlich
 einige noch auf meiner Recycling-Map [1] einbauen, in der ich jetzt
 wie wild umeinander herscrollen musste um einen 429er zu
 provozieren.

Am einfachsten lässt sich der Unterschied z.B. mit Firebug in Firefox
(oder auch den Entwicklertools in Chrome) nachvollziehen: Während
deine Recycling-Karte für die BBox genau eine Abfrage absetzt, teilt
die Briefkastenkarte die BBox in viele kleine Unterabschnitte auf und
setzt für jeden dieser Abschnitte einen eigenen Request ab. Das meinte
ich eingangs mit fluten. Serialisieren würde hier bedeuten, immer
nur genau einen Request gleichzeitig abzusetzen.

 Ich glaube ich baue zusätzlich auch noch ein, dass man während
 eine Abfrage mit Sanduhr bis zum Timeout läuft auch das
 wegscrollen verbietet.

Alternativ wäre auch ein /api/kill_my_queries beim Scrollen der Seite
machbar. Dadurch werden noch ausstehende Queries auf dem Server
einfach abgebrochen.

Gruß,
mmd

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Eigene OSM-Karte mit Overpass

[mmd]

Hallo,

Am 09.05.2015 um 22:13 schrieb Benjamin Grimm-Lebsanft:
 Hallo Markus,
 
 ist vielleicht die Briefkastenkarte sowas was du suchst:
 http://briefkastenkarte.de/
 
 Im Blog dazu gibt es auch eine gute Anleitung wie sie gemacht wurde:
 http://blog.briefkastenkarte.de/

leider kann ich diese Karte zur Zeit nur eingeschränkt weiterempfehlen,
da sie die Overpass API regelrecht mit Anfragen flutet.

Mit der neuen Quota-Regel für die Overpass API [2] werden inzwischen
auch etliche Abfragen mit einem Fehler abgewiesen (429 Too Many
Requests). Ob dadurch Briefkästen nicht angezeigt werden oder einfach
eine neue Abfrage abgesetzt wird, habe ich mir allerdings nicht mehr
genau angesehen.

Ich kann mir gut vorstellen, dass die Karte selbst unschuldig ist und
leaflet-layer-overpass [3] im Hintergrund für die vielen Abfragen sorgt.
Das müsste sich vielleicht jemand mal in Ruhe im Gesamtkontext zu Gemüte
führen. Ein Github-Ticket findet sich übrigens unter [1].

Ansonsten würde ich mir auch mal uMap ansehen, die lässt sich bestimmt
auch gut in andere Seiten einbetten.

Gruß,
mmd


[1] https://github.com/dbretschneider/briefkastenkarte.de/issues/8
[2] https://lists.openstreetmap.org/pipermail/talk/2015-April/072661.html
[3] https://github.com/kartenkarsten/leaflet-layer-overpass

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Overpass API: Link zur Beispielsammlung im Wiki

[mmd]

Hallo,

in Rolands Vortrag Schatzsuche in OSM [1] kam die Frage nach einer
Beispielsammlung für Overpass API-Abfragen auf.

Im Wiki gibt es dazu bereits eine recht umfassende, bisweilen etwas
unstrukturierte Sammlung [2], in der auch einiges an Beispielen von
stackoverflow, help osm und weiteren Seiten mit eingeflossen ist. Wenn ihr
noch mehr tolle Queries habt, bitte gerne ergänzen!

Übrigens: die neue Seite Overpass API by Example [3] sucht noch
Freiwillige für die Übersetzung.

Gruß,
mmd

[1] https://www.youtube.com/watch?v=VJItOHImN7A
[2] http://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung
[3] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_API_by_Example



--
View this message in context: 
http://gis.19327.n5.nabble.com/Overpass-API-Link-zur-Beispielsammlung-im-Wiki-tp5837888.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?

[mmd]

Pieren wrote
 On Thu, Jul 24, 2014 at 5:33 PM, Christian Quest
 In my last overpass test with the new out center feature, it looked
 like
 it was working only with XML output, not with the JSON (not GeoJSON) one.
 
 It's already reported:
 https://github.com/drolbr/Overpass-API/issues/93
 
 Pieren

Right, some of the missing bits for JSON support are already implemented in
the out_geom_json branch. However, Roland hasn't merged this branch into
the master branch yet.

https://github.com/drolbr/Overpass-API/tree/out_geom_json

Best
mmd




--
View this message in context: 
http://gis.19327.n5.nabble.com/Overpass-API-Overpass-QL-center-and-centroid-function-tp5812491p5812549.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Overpass API / Overpass QL: center (and centroid) function?

[mmd]

Stefan Keller wrote
 I'm still struggling even with the XML output.
 My actual goal is to display the result set of the Dairy/Cheese
 Makers query in uMap.
 When I apply the query below to http://overpass-turbo.osm.ch/ the result
 is OK
 (displayed POIs: 386, Lines: 300, Polygons: 138).
 
 But when I add this URL as remote data to uMap, there are less markers
 displayed.
 It seems again that there is a problem with the ways/areas:

I created a new issue for umap now [1], as I believe the center tag is not
yet handled during import. Please feel free to enhance the ticket as needed.

[1]
https://bitbucket.org/yohanboniface/umap/issue/94/overpass-api-extension-center-in-osm




--
View this message in context: 
http://gis.19327.n5.nabble.com/Overpass-API-Overpass-QL-center-and-centroid-function-tp5812491p5812559.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] traduction flyer carte destiné au transport routier poids-lourds

[mmd]

Frédéric Rodrigo-2 wrote
 Le 19/07/2014 19:41, David Crochet a écrit :
 Bonjour

 Dans le même principe, en tant qu'outils QA, est-ce possible de
 réutiliser les données d'info manquantes de [1] pour les intégrées à
 Osmose par exemple ?

 [1] http://maxheight.bplaced.net/overpass/map.html
 
 En fait c'est déjà dans osmose...
 
 http://osmose.openstreetmap.fr/fr/map/#item=level=1%2C2%2C3tags=maxheight

Par contre, la logique c'est un peu différent pour OSM Truck QA map: il y a
plus de types (Passage couvert, tunnel, Voie ferrée, Route sous un pont) /
différent types des highway=*, mais il n'y a pas de base de données pour
sauvegarder les faux positifs (c'est indiqué par les maxheight=none tags).
En plus, toutes les analyses sont fait en temps réel pour tous le monde dans
le browser (supporté par Overpass API).

Veuillez excuser mon francais, merci. :)

Cdt,
mmd
(auteur OSM Truck QA Map)




--
View this message in context: 
http://gis.19327.n5.nabble.com/traduction-flyer-carte-destine-au-transport-routier-poids-lourds-tp5812031p5812058.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: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source

[mmd]

Andreas Schmidt wrote
 also das Beispiel tüschenbroicher mühle kann ich per OSM finden.
 Haben die ARDler was falsch gemacht?

openrouteservice hat offenbar ein Problem mit Umlauten. Mit
Tueschenbroicher Muehle funktioniert die Suche.

Gruß,
mmd





--
View this message in context: 
http://gis.19327.n5.nabble.com/ARD-Ratgeber-Internet-Alternativen-zu-Google-Maps-Open-Source-tp5807193p5807233.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Daten herunterladen in JOSM

[mmd]

Johannes wrote
 Am 17.04.2014 01:32, schrieb Paul Hartmann:
 Es werden dort allerdings nur TMS-Ebenen unterstützt (und kein WMS).
 
 D.h. die Tiles vom deutschen Stil kann man nicht in den Download-Dialog
 packen, richtig? Gruß Johannes

Doch, das sollte funktionieren. Ich verwende dafür folgende TMS-URL in JOSM
(eintragen unter WMS/TMS - TMS hinzufügen):

tms[18]:http://{switch:a,b,c,d}.tile.openstreetmap.de/tiles/osmde/{zoom}/{x}/{y}.png

Im Download-Dialog lässt sich dieser neue TMS-Layer anschließend auswählen.




--
View this message in context: 
http://gis.19327.n5.nabble.com/Daten-herunterladen-in-JOSM-tp5803437p5803476.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de