Les clients OSM sont codés en fonction de ce que OSM envoie, non ? Je veux dire que si OSM passe au vectoriel, alors les clients vont (bien obligés) suivre.
Non
OSM c'est avant tout de la donnée. De la donnée brut. Il faut alors la rendre (générer la carte). Et là plusieurs serveurs existent.
Ensuite, côté client, ben en général c'est souvent du WMS / WFS / TMS / KML. En dehors de ça y'a pas énormément de choses.
Et les clients sont souvent des clients TMS (tuiles) car c'est quand même simple.
Les clients ne sont pas spécifiques à OSM, loin de là. En général ce sont des clients qui lisent les formats OGC (plus ou moins).
J'avoue être surpris par ces problèmes de "rendu de carte" alors que la moindre config vendue actuellement est capable de faire tourner un jeu 3D du genre d'OpenArena. À priori ça me paraît capable de faire le rendu d'une carte à partir de données de base :|
Le problème n'est pas uniquement en temps de rendu. Déjà il y a quand même un côté idiot à vouloir que tout le monde rende la même donnée, ça va un peu à l'encontre d'une mutualisation de moyen et fait du boulot auprès de tout le monde.
Ensuite, je pense que tu sous-estime le temps de dessin d'une (ou plusieurs) tuiles. Si les gens apprécient Google Maps (comme dit dans l'article) c'est parce que ça va vite. Il est illusoire de croire qu'on peut avoir les mêmes performances sans un minimum de prégénération de tuiles.
Bon après c'est pas si blanc/noir, lorsqu'on envoi un kml à afficher à Google il l'envoi sur ces serveurs et le tuile côté serveur plutôt que de le rendre côté client. Idem pour les markers.
Mais concrètement, côté temps de rendu on aura pas de bonnes performances. Et un moteur de rendu c'est pas si léger que ça non plus.
Une tuile vectorielle c'est déjà différent car c'est juste que ce n'est pas une image bitmap qui est envoyée mais une image vectorielle. Une partie du traitement est déjà faite.
Pour présenter un peu les autre problématiques au rendu côté client : le placement des étiquettes de lieux, nom de rue, etc. C'est une opération qui est loin d'être négligeable. Lesquelles afficher. Gestion de conflits. Gestion d'importance. Comment faire pour que leur position ne dépende pas de la vue du client. etc.
[^] # Re: Protocole adapté ?
Posté par CrEv (site web personnel) . En réponse au journal Google n'est pas notre ennemi (avec des morceaux d'OSM dedans). Évalué à 2.
Non
OSM c'est avant tout de la donnée. De la donnée brut. Il faut alors la rendre (générer la carte). Et là plusieurs serveurs existent.
Ensuite, côté client, ben en général c'est souvent du WMS / WFS / TMS / KML. En dehors de ça y'a pas énormément de choses.
Et les clients sont souvent des clients TMS (tuiles) car c'est quand même simple.
Les clients ne sont pas spécifiques à OSM, loin de là. En général ce sont des clients qui lisent les formats OGC (plus ou moins).
Le problème n'est pas uniquement en temps de rendu. Déjà il y a quand même un côté idiot à vouloir que tout le monde rende la même donnée, ça va un peu à l'encontre d'une mutualisation de moyen et fait du boulot auprès de tout le monde.
Ensuite, je pense que tu sous-estime le temps de dessin d'une (ou plusieurs) tuiles. Si les gens apprécient Google Maps (comme dit dans l'article) c'est parce que ça va vite. Il est illusoire de croire qu'on peut avoir les mêmes performances sans un minimum de prégénération de tuiles.
Bon après c'est pas si blanc/noir, lorsqu'on envoi un kml à afficher à Google il l'envoi sur ces serveurs et le tuile côté serveur plutôt que de le rendre côté client. Idem pour les markers.
Mais concrètement, côté temps de rendu on aura pas de bonnes performances. Et un moteur de rendu c'est pas si léger que ça non plus.
Une tuile vectorielle c'est déjà différent car c'est juste que ce n'est pas une image bitmap qui est envoyée mais une image vectorielle. Une partie du traitement est déjà faite.
Pour présenter un peu les autre problématiques au rendu côté client : le placement des étiquettes de lieux, nom de rue, etc. C'est une opération qui est loin d'être négligeable. Lesquelles afficher. Gestion de conflits. Gestion d'importance. Comment faire pour que leur position ne dépende pas de la vue du client. etc.